Assurance

[Tom Golson <>]

Isn't the AD stored secret issue, unsalted, MD4 hashes, not RC4 encryption?

--Tom

On 2/26/13 10:28 AM, Brian Arkills wrote:
> 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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature