SSL appears to be broken in 8-STABLE/RELEASE

[Chris H]

Greetings Matthew, and thank you very much for your reply.
On Sat, December 19, 2009 12:33 am, Matthew Seaman wrote:
> Chris H wrote:
>
>> Greetings,
>> A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to
>> indicate that changes in SSL have made it virtually unusable. I've spent the
>> past 3 days attempting to (re)create an SSL enabled virtual host that serves
>> web based access to local mail. Since it's local, I'm using self-signed certs
>> following a scheme that has always worked flawlessly for the past 9 yrs.
>> However, now having installed 8,
>> it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert"
>> (ff-3.56).
>> Other gecko based, and non-gecko based UA's throw similar, as well as
>> openssl's s_client. After immense research, the only thing I can find that
>> might best explain it is a recent SA patch applied to FreeBSD's src
>> (SA-09:15). After reading what the
>> patch provides. I am able to better understand the error messages thrown to
>> /var/messages when attempting to negotiate a secure session in a UA:
>>
>
> Your analysis is correct.  You've hit the exact problem used as the test case
> in all the investigations into the SSL injection attach mitigated in SA-09:15.
> Essentially what happens is that your clients make an initial anonymous (on the
>  client side) connection to the SSL site.  Then (as a consequence perhaps of
> user actions), the SSL site requires the user side to authenticate itself by
> presenting a certificate.  This authentication process entails renegotiating the
> whole client -> server SSL connection, and that is precisely what was diked out
> of openssl-0.9.6m as it is the route to exploiting the security flaw.
>
> There is an update to the SSL protocol in the works that will properly close
> the vulnerability and still allow useful things like renegotiation -- see
>
> https://datatracker.ietf.org/idtracker/draft-ietf-tls-renegotiation/
>
>
> This has taken what seems like a veritable age for the IETF to process, but in
> reality it is moving with all dispatch to get the fix in place.
>
> So, at the moment, we have a band-aid that fixes the vulnerability, but that
> breaks some sites.  In the future we will have a correct fix that restores the
> desirable functionality.  Between now and then, your site is going to have
> difficulties.
>
> Options:
>
>
> * Just wait. Leave the site broken (but invulnerable to the attack) until
> the proper fix comes out.  I somehow doubt that this will be acceptable.
>
> * Temporarily (or permanently) switch to some other form of authentication
> than using SSL client certificates.  Likely to require significant re-engineering
> of your site, and probably quite a lot of user re-education and other chores.
>
> * Accept the risk of the SSL injection attack, downrev to openssl-0.8.6l
> and put in place whatever other mitigation you can think of to protect the site.
> For instance, fire-walling off all access except to known
> good IP numbers.
>
> To find out more about the attack, see Marsh Ray's blog at
> http://extendedsubset.com/
> which has links to many useful resources.
>
> Cheers,
>
>
> Matthew

WOW. I am /extremely/ grateful for your thoughtful, and very informative reply.
All points well taken. Given an already well secured network. I'll opt for
"door number 3" - back-patch openssl, and flag that section of the
tree as HOLD. While closely monitoring openssl for the "new and improved"
version. :)

In all honesty, I'm quite impressed with openssl - that it took /so/ long for
this "hole" to be found. Just wish a better "plug" could have been found
during the interim. :)

Thank you again Matthew, for taking the time to provide such an informative,
and thoughtful response.

--Chris H
>
>
> --
> Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
> Flat 3
> PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
> Kent, CT11 9PW
>
>
>