Date: Fri, 18 Dec 2009 17:32:41 -0800 (PST) From: "Chris H" <chris#@1command.com> To: freebsd-stable@freebsd.org Subject: SSL appears to be broken in 8-STABLE/RELEASE Message-ID: <f196357e2f75a3f986ab0c4dd04a7697.HRCIM@webmail.1command.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f196357e2f75a3f986ab0c4dd04a7697.HRCIM>