Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Dec 2009 08:33:14 +0000
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        Chris H <chris#@1command.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: SSL appears to be broken in 8-STABLE/RELEASE
Message-ID:  <4B2C8FCA.9000105@infracaninophile.co.uk>
In-Reply-To: <f196357e2f75a3f986ab0c4dd04a7697.HRCIM@webmail.1command.com>
References:  <f196357e2f75a3f986ab0c4dd04a7697.HRCIM@webmail.1command.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE343BE4905A8666D985C072F
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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 pas=
t 3 days
> attempting to (re)create an SSL enabled virtual host that serves web ba=
sed 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 in=
stalled 8,
> it isn't working. The browser(s) throw "ssl_error_handshake_failure_ale=
rt"
> (ff-3.56).
> Other gecko based, and non-gecko based UA's throw similar, as well as o=
penssl'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 read=
ing what the
> patch provides. I am able to better understand the error messages throw=
n 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-0=
9:15.
Essentially what happens is that your clients make an initial anonymous (=
on the=20
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 p=
resenting
a certificate.  This authentication process entails renegotiating the who=
le 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 cl=
ose the
vulnerability and still allow useful things like renegotiation -- see=20

  https://datatracker.ietf.org/idtracker/draft-ietf-tls-renegotiation/

This has taken what seems like a veritable age for the IETF to process, b=
ut 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 t=
hat breaks
some sites.  In the future we will have a correct fix that restores the d=
esirable
functionality.  Between now and then, your site is going to have difficul=
ties.

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 acc=
eptable.

       * Temporarily (or permanently) switch to some other form of authen=
tication
         than using SSL client certificates.  Likely to require significa=
nt=20
         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 p=
rotect
         the site.  For instance, fire-walling off all access except to k=
nown
         good IP numbers.

To find out more about the attack, see Marsh Ray's blog at http://extende=
dsubset.com/
which has links to many useful resources.

	Cheers,

	Matthew

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


--------------enigE343BE4905A8666D985C072F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkssj88ACgkQ8Mjk52CukIwfCwCeIWTQxuxOFOK9yE92ttwNifJO
4ukAn3zBpsJogDrFLD+anNHatkco4T3V
=FomH
-----END PGP SIGNATURE-----

--------------enigE343BE4905A8666D985C072F--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B2C8FCA.9000105>