SSL appears to be broken in 8-STABLE/RELEASE
- From: "Chris H" <chris#@1command.com>
- Date: Fri, 18 Dec 2009 17:32:41 -0800 (PST)
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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: SSL appears to be broken in 8-STABLE/RELEASE
- From: Maxim Dounin
- Re: SSL appears to be broken in 8-STABLE/RELEASE
- From: Matthew Seaman
- Re: SSL appears to be broken in 8-STABLE/RELEASE
- From: Clifton Royston
- Re: SSL appears to be broken in 8-STABLE/RELEASE
- From: Peter C. Lai
- Re: SSL appears to be broken in 8-STABLE/RELEASE
- Prev by Date: Re: iSCSI initiator and Dell PowerVault MD3000i
- Next by Date: Re: SSL appears to be broken in 8-STABLE/RELEASE
- Previous by thread: [releng_8_0 tinderbox] failure on i386/i386
- Next by thread: Re: SSL appears to be broken in 8-STABLE/RELEASE
- Index(es):
Relevant Pages
|
