Assurance

["Capehart,Jeffrey D" <>]

Joe,

Thank you for the excellent reference and tool.  The SSL Labs website does a 
fantastic job of documenting server encryption!

Unfortunately, my tests gave a "C" grade to our servers, so it looks like 
there is room for improvement.

For anyone testing the Silver "Protected Channel" requirements, this is a 
great way to document the encryption supported.
https://www.ssllabs.com/ssldb/index.html

For Higher Ed, would it be reasonable to use exception (footnote) #22 and 
allow RC4 Encryption in SSL/TLS and still claim NIST compliance?

NIST TLS-SSL SP800-52:

TLS_RSA_WITH_RC4_128_SHA   (#22)

(#22) RC4 is not a FIPS-approved cryptographic algorithm. For this reason, 
cipher suites with RC4 should be offered only when communicating with 
non-government entities in limited, low risk situations for the transfer of 
non-Federal data when a FIPS-approved encryption algorithm is not supported. 
Normally this cipher suite should not be offered.

Jeff

Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882

http://oia.ufl.edu



-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Joe St Sauver
Sent: Monday, February 25, 2013 4:02 PM
To: 

Subject: Re: [Assurance] Question on Protected Channel - SSL/TLS

"Capehart,Jeffrey D" 
<>
 asked:

#So, what level of testing do you think is necessary to validate that a 
#Protected Channel is used?
#
#Per the v1.2 IAAF, typical SSL/TLS should provide the protections.  

Let me preface my comments by noting that I'm *not* an IT auditor, and this 
is not audit advice, just some points for your consideration...

A year or two ago I did a talk, "SSL/TLS Certificates: Giving Your Use of 
Server Certificates a Hard Look," see 
http://pages.uoregon.edu/joe/hardlook/hard-look.pdf

As part of putting that talk together, I looked at a set of higher ed 
institutions uisng the tool that's available at:
https://www.ssllabs.com/ssldb/index.html

The results weren't particularly pretty :-(

Lots of sites have issues with things like:

-- permitting SSL 2.0 (they shouldn't -- SSL2.0 is insecure)
-- doing renegotiation insecurely
-- accepting too-short ciphers
-- using too-short cert signatures
-- running out-of-date versions of Apache (or whatever server software 
   they're using)
-- not using a web application firewall
-- and the list goes on...

And of course, lots of users are using browsers with their own set of SSL 
issues, including things like failing to handle OCSP/CRL checking sanely, or 
failing to support secure versions of the TLS protocol.

So, if it were me, I'd start by hitting the SSL Labs page mentioned above, 
just to see what it can detect that's worth digging into more deeply. A lot 
of sites appear to be doing SSL/TLS, but when you give them a hard look, 
their installations aren't very secure "under the hood."

Beyond that, as discussed in "Leveraging Certificates for Improved Security,"
http://pages.uoregon.edu/joe/leveraging-certificates/leveraging-certs.pdf
I'd *like* to see an EV cert used, and I'd also like to see HTTP Strict 
Transport Security (HSTS) enabled, and I'd like to see users running 
Certificate Patrol...

Hope this gives you at least a few ideas to explore...

Regards,

Joe