Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Maxim Dounin writes: While talking about often - do you have any stats? Anyway, this is quite a differenet from all client cert-powered apps you stated in your previous message. IIS defaults to renegotiation when doing client cert auth, and Apache certainly can (possibly must? I don't know) work this way as well. See Ray and Dispensa's original paper. http://extendedsubset.com/Renegotiating_TLS.pdf In particular, practical attacks against HTTPS client certificate authentication have been demonstrated against recent versions of both Microsoft IIS and Apache httpd on a variety of platforms and in conjunction with a variety of client applications. So, sure; all is an exaggeration, but it's much less wrong than rarely used. - not patching is not an option as it leaves unsecure much more installations. Patching/not patching is not always a black and white question whose answer is always yes. The question is far more gray when the patch breaks protocol compat with a major protocol feature. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Actually, pretty much anyone who uses client certificates in an enterprise environment is likely to have a problem with this, which is why the IETF TLS working group is working on publishing a protocol fix. It looks like that RFC should be published, at Proposed Standard, in a few weeks, and most vendors look prepared to release implementations of the fix immediately thereafter (as soon as the relevant constants are assigned by IANA). -GAWollman This advisory kinda made big problem here in local (things stopped working). I had to do rollback this update because of session renegotiation breakage. Is there some workaround to make things work along with this advisory? Maybe switch to ports/security/openssl ? Can anyone comment on this one? Thanks in advance. =bc ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Bogdan Ćulibrk b...@default.rs writes: This advisory kinda made big problem here in local (things stopped working). I had to do rollback this update because of session renegotiation breakage. That's the whole point, the patch disables session renegotiation because it's fundamentally broken. Is there some workaround to make things work along with this advisory? You didn't mention *what* stopped working. Maybe switch to ports/security/openssl ? Won't make any difference. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Dag-Erling Smørgrav wrote: Bogdan Ćulibrk b...@default.rs writes: This advisory kinda made big problem here in local (things stopped working). I had to do rollback this update because of session renegotiation breakage. That's the whole point, the patch disables session renegotiation because it's fundamentally broken. Is there some workaround to make things work along with this advisory? You didn't mention *what* stopped working. Maybe switch to ports/security/openssl ? Won't make any difference. DES Hello, basically whole communication between two application relied on using exactly this funcionality in openssl. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Bogdan Ćulibrk b...@default.rs writes: basically whole communication between two application relied on using exactly this funcionality in openssl. In that case, the only choice you have is to revert to the previous version... DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Dan Lukes d...@obluda.cz writes: Even after the patch has been installed, my browser is still able to connect to SSL aware HTTP servers. My MUA is still sending/receiving emails over SMTP/SSL and IMAP/SSL ... Do you use client-side certificates? I'm not saying you have no problem, i'm saying the problem is not as general as you claim. So we need exact description of your problem. Language barrier. What he actually meant was all communication between these two applications that we use relies on session renegotiation without specifying exactly *which* applications, probably because they're in-house and / or confidential. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
RE: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Actually, pretty much anyone who uses client certificates in an enterprise environment is likely to have a problem with this, which is why the IETF TLS working group is working on publishing a protocol fix. It looks like that RFC should be published, at Proposed Standard, in a few weeks, and most vendors look prepared to release implementations of the fix immediately thereafter (as soon as the relevant constants are assigned by IANA). -GAWollman This advisory kinda made big problem here in local (things stopped working). I had to do rollback this update because of session renegotiation breakage. Is there some workaround to make things work along with this advisory? Maybe switch to ports/security/openssl ? Can anyone comment on this one? Thanks in advance. You will have to wait on the TLS Working Group in the IETF to finish if your application needs renegotiation. The HOT PAGE on this topic for the industry is here: http://www.icasi.org/tls-ssl.html ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Dag-Erling Smørgrav d...@des.no writes: The correct anser is: answer, even DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Dag-Erling Sm??rgrav writes: Do you use client-side certificates? This is probably the original poster's problem. FreeBSD Security Advisory FreeBSD-SA-09:15.ssl made clear that the patch fixes the protocol bug by removing the broken feature (session renegotiation), but stated incorrectly that session renegotiation is rarely used. In fact, client certificates work using renegotiation as the underlying mechanism, and client cert auth is pretty common. The advisory stated: NOTE WELL: This update causes OpenSSL to reject any attempt to renegotiate SSL / TLS session parameters. As a result, connections in which the other party attempts to renegotiate session parameters will break. In practice, however, session renegotiation is a rarely-used feature, so disabling this functionality is unlikely to cause problems for most systems. So, yeah, everybody: This patch breaks all your client cert-powered apps. Probably the advisory should have mentioned that. :) That's why we'll all be really happy when the new, fixed version of TLS comes out and our TLS libraries all support the new version. Until then, we'll have to either stop using client cert auth, or continue to use it with some risk, or continue to use it while also employing flimsy mitigiation methods like allowing only whitelisted client IPs to connect (increasing the attacker's hassle somewhat, but not making attacks impossible). It might also, or might not, help to require another form of auth from the client, such as passwords or magic strings in the SOAP header or whatever. Finally, the exploit scenarios I've heard of so far resemble cross-site request forgery, in that the attacker can insert bad messages into an otherwise good session. If you're protecting a web app with TLS client cert auth, you'll need to audit that app for bugs like XSS and CSRF regardless of this TLS problem. Depending on my mood, and please note I haven't had any coffee yet, I might even say that this TLS problem is the least of the average web application's woes (even though this TLS problem is not insignificant). Ok, coffee time. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Hello! On Thu, Dec 10, 2009 at 10:37:18AM -0800, Chris Palmer wrote: Dag-Erling Sm??rgrav writes: Do you use client-side certificates? This is probably the original poster's problem. FreeBSD Security Advisory FreeBSD-SA-09:15.ssl made clear that the patch fixes the protocol bug by removing the broken feature (session renegotiation), but stated incorrectly that session renegotiation is rarely used. In fact, client certificates work using renegotiation as the underlying mechanism, and client cert auth is pretty common. The advisory stated: NOTE WELL: This update causes OpenSSL to reject any attempt to renegotiate SSL / TLS session parameters. As a result, connections in which the other party attempts to renegotiate session parameters will break. In practice, however, session renegotiation is a rarely-used feature, so disabling this functionality is unlikely to cause problems for most systems. So, yeah, everybody: This patch breaks all your client cert-powered apps. Probably the advisory should have mentioned that. :) It's not true. Patch (as well as OpenSSL 0.9.8l) breaks only apps that do not request client certs in initial handshake, but instead do it via renegotiation. It's not really commonly used feature. Maxim Dounin ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Maxim Dounin writes: It's not true. Patch (as well as OpenSSL 0.9.8l) breaks only apps that do not request client certs in initial handshake, but instead do it via renegotiation. It's not really commonly used feature. The ideal case is not the typical case: http://extendedsubset.com/Renegotiating_TLS_pd.pdf The plain fact is that client cert auth often needs reneg in apps as deployed in the world. Often, web servers need to check (for example) a virtual-host-specific configuration before realizing they need to request client cert auth. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Michal m...@infosec.pl writes: Is there a way to reinstall just these libraries or to get them from the net in a secure manner i.e. signed? # freebsd-update fetch install DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Dag-Erling Smørgrav wrote: Michal m...@infosec.pl writes: Is there a way to reinstall just these libraries or to get them from the net in a secure manner i.e. signed? # freebsd-update fetch install It is what I was looking for, thank you very much. Michal -- Power tends to corrupt, and absolute power corrupts absolutely. -John Dalberg-Acton ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
FreeBSD Security Advisories wrote: b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch # cd /usr/src/secure/lib/libcrypto # make obj make depend make includes make make install NOTE: On the amd64 platform, the above procedure will not update the lib32 (i386 compatibility) libraries. On amd64 systems where the i386 compatibility libraries are used, the operating system should instead be recompiled as described in URL:http://www.FreeBSD.org/handbook/makeworld.html Don't quite understand - do we really have to rebuild and reinstall whole world on amd64 just to update these libraries? Rebuilding is not a problem here but reinstalling can be painful because of host-based IDS, custom chflags and so on. Looks like a terrible waste of resources. Is there a way to reinstall just these libraries or to get them from the net in a secure manner i.e. signed? Cheers. Michal -- Lost time is never found again. -Benjamin Franklin ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-09:15.sslSecurity Advisory The FreeBSD Project Topic: SSL protocol flaw Category: contrib Module: openssl Announced: 2009-12-03 Credits:Marsh Ray, Steve Dispensa Affects:All supported versions of FreeBSD. Corrected: 2009-12-03 09:18:40 UTC (RELENG_8, 8.0-STABLE) 2009-12-03 09:18:40 UTC (RELENG_8_0, 8.0-RELEASE-p1) 2009-12-03 09:18:40 UTC (RELENG_7, 7.2-STABLE) 2009-12-03 09:18:40 UTC (RELENG_7_2, 7.2-RELEASE-p5) 2009-12-03 09:18:40 UTC (RELENG_7_1, 7.1-RELEASE-p9) 2009-12-03 09:18:40 UTC (RELENG_6, 6.4-STABLE) 2009-12-03 09:18:40 UTC (RELENG_6_4, 6.4-RELEASE-p8) 2009-12-03 09:18:40 UTC (RELENG_6_3, 6.3-RELEASE-p14) CVE Name: CVE-2009-3555 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit URL:http://security.FreeBSD.org/. I. Background The SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols provide a secure communications layer over which other protocols can be utilized. The most widespread use of SSL/TLS is to add security to the HTTP protocol, thus producing HTTPS. FreeBSD includes software from the OpenSSL Project which implements SSL and TLS. II. Problem Description The SSL version 3 and TLS protocols support session renegotiation without cryptographically tying the new session parameters to the old parameters. III. Impact An attacker who can intercept a TCP connection being used for SSL or TLS can cause the initial session negotiation to take the place of a session renegotiation. This can be exploited in several ways, including: * Causing a server to interpret incoming messages as having been sent under the auspices of a client SSL key when in fact they were not; * Causing a client request to be appended to an attacker-supplied request, potentially revealing to the attacker the contents of the client request (including any authentication parameters); and * Causing a client to receive a response to an attacker-supplied request instead of a response to the request sent by the client. IV. Workaround No workaround is available. V. Solution NOTE WELL: This update causes OpenSSL to reject any attempt to renegotiate SSL / TLS session parameters. As a result, connections in which the other party attempts to renegotiate session parameters will break. In practice, however, session renegotiation is a rarely-used feature, so disabling this functionality is unlikely to cause problems for most systems. Perform one of the following: 1) Upgrade your vulnerable system to 6-STABLE, 7-STABLE, or 8-STABLE, or to the RELENG_8_0, RELENG_7_2, RELENG_7_1, RELENG_6_4, or RELENG_6_3 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 6.3, 6.4, 7.1, 7.2, and 8.0 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-09:15/ssl.patch # fetch http://security.FreeBSD.org/patches/SA-09:15/ssl.patch.asc b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch # cd /usr/src/secure/lib/libcrypto # make obj make depend make includes make make install NOTE: On the amd64 platform, the above procedure will not update the lib32 (i386 compatibility) libraries. On amd64 systems where the i386 compatibility libraries are used, the operating system should instead be recompiled as described in URL:http://www.FreeBSD.org/handbook/makeworld.html VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. CVS: Branch Revision Path - - RELENG_6 src/crypto/openssl/ssl/s3_pkt.c1.1.1.10.2.1 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.14.2.3 src/crypto/openssl/ssl/s3_lib.c1.1.1.10.2.1 RELENG_6_4 src/UPDATING1.416.2.40.2.12 src/sys/conf/newvers.sh 1.69.2.18.2.14 src/crypto/openssl/ssl/s3_pkt.c 1.1.1.10.12.1 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.14.2.1.6.2 src/crypto/openssl/ssl/s3_lib.c 1.1.1.10.12.1 RELENG_6_3 src/UPDATING1.416.2.37.2.19 src/sys/conf/newvers.sh
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Hi, = FreeBSD-SA-09:15.sslSecurity Advisory The FreeBSD Project [..] b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch # cd /usr/src/secure/lib/libcrypto # make obj make depend make includes make make install Did you mean secure/lib/libssl rather than libcrypto? Regards, -- Niels. -- BitKat zo weten we nog steeds niet of de steganosaurus wel echt bestaan heeft ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Thu, Dec 03, 2009 at 02:09:36PM +0100, Niels Bakker wrote:
=
FreeBSD-SA-09:15.sslSecurity Advisory
The FreeBSD Project
[..]
b) Execute the following commands as root:
# cd /usr/src
# patch /path/to/patch
# cd /usr/src/secure/lib/libcrypto
# make obj make depend make includes make make install
Did you mean secure/lib/libssl rather than libcrypto?
Most probably, yes: both commits to 0.9.8k reference files
in libssl,
http://cvs.openssl.org/chngview?cn=18794
http://cvs.openssl.org/chngview?cn=18791
-
[/usr/src/secure/lib]$ grep -Er '(s3_srvr|s3_lib)' *
libssl/Makefile:s3_both.c s3_clnt.c s3_enc.c s3_lib.c s3_meth.c
s3_pkt.c \
libssl/Makefile:s3_srvr.c ssl_algs.c ssl_asn1.c ssl_cert.c ssl_ciph.c \
:: r...@void : 20:06:59 : /usr/src/secure/lib
$ grep -Er '(s3_srvr|s3_lib|ssl_err|s3_pkt|ssl3\.h)' *
libssl/Makefile:s3_both.c s3_clnt.c s3_enc.c s3_lib.c s3_meth.c
s3_pkt.c \
libssl/Makefile:s3_srvr.c ssl_algs.c ssl_asn1.c ssl_cert.c ssl_ciph.c \
libssl/Makefile:ssl_err.c ssl_err2.c ssl_lib.c ssl_rsa.c ssl_sess.c
ssl_stat.c \
libssl/Makefile:INCS= dtls1.h kssl.h ssl.h ssl2.h ssl23.h ssl3.h tls1.h
libssl/man/ssl.3:.IP \fBssl3.h\fR 4
libssl/man/ssl.3:.IX Item ssl3.h
-
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
On Thu, 3 Dec 2009 09:30:39 GMT, FreeBSD Security Advisories security-advisor...@freebsd.org said: NOTE WELL: This update causes OpenSSL to reject any attempt to renegotiate SSL / TLS session parameters. As a result, connections in which the other party attempts to renegotiate session parameters will break. In practice, however, session renegotiation is a rarely-used feature, so disabling this functionality is unlikely to cause problems for most systems. Actually, pretty much anyone who uses client certificates in an enterprise environment is likely to have a problem with this, which is why the IETF TLS working group is working on publishing a protocol fix. It looks like that RFC should be published, at Proposed Standard, in a few weeks, and most vendors look prepared to release implementations of the fix immediately thereafter (as soon as the relevant constants are assigned by IANA). -GAWollman ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
