Assurance

[Brian Arkills <>]

Accepting RC4 would resolve the Active Directory stored secrets issue too.

> -----Original Message-----
> From: 
> 
>  [
> ]
>  On Behalf Of Capehart,Jeffrey D
> Sent: Tuesday, February 26, 2013 8:21 AM
> To: 
> 
> Subject: RE: [Assurance] Question on Protected Channel - SSL/TLS
> 
> 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: 
> 
>  [
> ]
>  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