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: kernel: TCP: [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after socket was closed, sending RST and removing tcpcb kernel: TCP: [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) kernel: TCP: [web.server.host.IP]:52153 to [web.server.host.IP]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after socket was closed, sending RST and removing tcpcb kernel: TCP: [web.server.host.IP]:52153 to [web.server.host.IP]:443 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) kernel: TCP: [web.server.host.IP]:60382 to [web.server.host.IP]:443 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after socket was closed, sending RST and removing tcpcb kernel: TCP: [web.server.host.IP]:60382 to [web.server.host.IP]:443 tcpflags 0x11<FIN,ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) So, if I understand things correctly. The patch prevents (re)negotiation. Making the likelihood of a successful "handshake" near null (as the log messages above show). I'm sure that some may be quick to point the finger at the self-signed cert being more likely the cause, I should add that while in fact quite unlikely, I too didn't completely rule that out. So I purchased one from startssl - money wasted. The results were the same. So it would appear that until something else is done to overcome the hole in current openssl, my only recourse is to back the patch out, and rebuild openssl && all affected ports - no? Thank you for all your time and consideration in this matter. --Chris H
This might have something to do with a libthr discussion I was CCed on. Someone mentioned something about removing a link to libthr in openssl but I can't remember if this was in the port or base openssl... On 2009-12-18 05:32:41PM -0800, 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: > > kernel: TCP: [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags > 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after > socket was closed, sending RST and removing tcpcb > kernel: TCP: [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags > 0x11<FIN,ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment > rejected (probably spoofed) > kernel: TCP: [web.server.host.IP]:52153 to [web.server.host.IP]:443 tcpflags > 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after > socket was closed, sending RST and removing tcpcb > kernel: TCP: [web.server.host.IP]:52153 to [web.server.host.IP]:443 tcpflags > 0x11<FIN,ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment > rejected (probably spoofed) > kernel: TCP: [web.server.host.IP]:60382 to [web.server.host.IP]:443 tcpflags > 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after > socket was closed, sending RST and removing tcpcb > kernel: TCP: [web.server.host.IP]:60382 to [web.server.host.IP]:443 tcpflags > 0x11<FIN,ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment > rejected (probably spoofed) > > So, if I understand things correctly. The patch prevents (re)negotiation. Making > the likelihood of a successful "handshake" near null (as the log messages above > show). I'm sure that some may be quick to point the finger at the self-signed > cert being more likely the cause, I should add that while in fact quite unlikely, > I too didn't completely rule that out. So I purchased one from startssl - money > wasted. The results were the same. So it would appear that until something else > is done to overcome the hole in current openssl, my only recourse is to back the > patch out, and rebuild openssl && all affected ports - no? > > Thank you for all your time and consideration in this matter. > > --Chris H > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"-- ==========================================================Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 ===========================================================
On Fri, Dec 18, 2009 at 05:32:41PM -0800, 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:...> So, if I understand things correctly. The patch prevents > (re)negotiation. Making the likelihood of a successful "handshake" > near null (as the log messages above show). I'm sure that some may be > quick to point the finger at the self-signed cert being more likely > the cause, I should add that while in fact quite unlikely, I too > didn't completely rule that out. So I purchased one from startssl - > money wasted. The results were the same. So it would appear that > until something else is done to overcome the hole in current openssl, > my only recourse is to back the patch out, and rebuild openssl && all > affected ports - no?You might want to check up on a security list to get a full understanding of the issue, and indeed depending on your application and network you may conclude that the best solution for your environment is to reverse out the patch. However, it's unlikely that the patch will be removed from circulation - most OSes and applications using TLS/SSL are undergoing a similar experience - because the security problem it prevents is both genuine and, as I understand it, an inherent design error in the protocol specification. If you allow renegotiation during the session, you also allow a man-in-the-middle attack to inject arbitrary data into the session. Depending on your app, the likelihood of this could be anywhere from small to huge, and the impact could be anywhere from negligible to disastrous. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services
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 -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091219/ffff60a0/signature.pgp
First my apologies for breaking the thread.
We also had this issue and tried to find an acceptable solution.
To make a long story short:
Please try to compile your application against the version of openssl
available in the ports tree.
As you already mentioned (SA-09:15) breaks renegotiation with base system's
openssl by fixing
a security issue ( it actually does).
Prerequisite for the following is, of course, to install
/usr/ports/security/openssl which will give you
openssl 0.9.8l . (You do not necessarily have to remove the base openssl)
You may then set 'WITH_OPENSSL_PORT=YES' to /etc/make.conf
and rebuild your application(s) with via the ports, they should then be
compiled correctly against the ports-version.
Or, but this will only work if if your application's configure script has a
switch to set the path to ssl
or openssl to the ports-openssl's location, something like
# setenv LD_LIBRARY_PATH /usr/local/lib ## this actually may be
removed after build
and configure with the appropriate option maybe alike
# ./configure --openssl-path=/usr/local/lib
Just make sure it compiled properly.
The output of ldd should show (apart from other):
# ldd application
/app/li/cation
......
libssl.so.5 => /usr/local/lib/libssl.so.5 (0x881bc000)
libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x88200000)
. ........
For the applications we use, this works with both versions of openssl on the
same box, without any i
interference.
Considerations about this ?
HTH
Hello! On Fri, Dec 18, 2009 at 05:32:41PM -0800, 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:[...]> So, if I understand things correctly. The patch prevents (re)negotiation. Making > the likelihood of a successful "handshake" near null (as the log messages above > show). I'm sure that some may be quick to point the finger at the self-signed > cert being more likely the cause, I should add that while in fact quite unlikely, > I too didn't completely rule that out. So I purchased one from startssl - money > wasted. The results were the same. So it would appear that until something else > is done to overcome the hole in current openssl, my only recourse is to back the > patch out, and rebuild openssl && all affected ports - no?If you are using Apache as server, you may consider using server-wide SSLVerifyClient (instead of per-location ones which require renegotiation). Maxim Dounin