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 > > > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[email protected]" -- =========================================================== 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 =========================================================== _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
