I haven’t investigated much (and I will not more), but since my upgrade to Mac OS 10.8 (Mountain Lion), Safari supports safe renegociation.
Meanwhile, I had received a laconic answer from Apple to my bug report saying that they “are aware of this issue”.
Note that Safari 6.0 on Lion did not (at least on my computer, if someone could confirm)… so same browser version, different OS, the system SSL library must have been – silently – updated.
Anyway, good move finally.
The other day I was shocked to find this entry in my Apache logs:
[error] SSL Library Error: 336068931 error:14080143:SSL routines:SSL3_ACCEPT:unsafe legacy renegotiation disabled
It occurs appears when I try to use a SSL client certificate with Safari. Of course, authentication is broken as it just fails on an 403 error page.
So it seems that Safari is the last browser which was not patched against CVE-2009-3555 !
2009 !! At least, I quickly checked the other browsers I had around and they were fine: IE, Firefox, Chrome… I am having an issue with Opera also, but although I have not identified the problem yet, it seems unrelated (and does not throw the same error).
Note that I reported the issue to Apple, but I did not receive any answer. Silence on the wire.
A solution has been finally brought up to fix CVE-2009-3555 and the temporary solution that broke client authentication.
At least, the IETF agreed on a fix as Marsh Ray informs us, though it will still take some weeks for the whole validation process to complete.
Moreover, as it requires both the servers and the clients to be patched, it will take months before the patches can be applied and one can have a working client authentification architecture. The longest will be the client side, of course, so I feel sorry for those who have a large park to manage.
As far as I am concerned, fortunately, I will just have a few browsers that I manage directly to update. Anyway, still more patience is needed !
As I just finished setting TLS and SASL to secure the access to my Postfix server, I realized that it was working only from inside my network.
What I got from my lan :
$ telnet mars 25 Trying 192.168.222.10... Connected to phocean.net. Connected to phocean.net. Escape character is '^]'. 220 phocean.net ESMTP Postfix (Debian/GNU) 220 phocean.net ESMTP Postfix (Debian/GNU) ehlo phocean.net ehlo phocean.net 250-phocean.net 250-phocean.net 250-PIPELINING 250-SIZE 200000000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH NTLM DIGEST-MD5 CRAM-MD5 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN
I shows well that the TLS handshake is initiated.
But from this outside, I just got this weired thing :
$ telnet phocean.net 25$ telnet phocean.net 25 Trying 81.64.194.119... Connected to phocean.net. Connected to phocean.net. Escape character is '^]'. 220 ********************************************** ehlo phocean.net ehlo phocean.net 502 5.5.2 Error: command not recognizedOf course, the firewall, a Cisco Pix one, was properly set to redirect port 25 UDP/TCP to my server.
However, I soon focused my effort on this equipment. I considered a while that the cause could be some filtering from my provider, but most probably, the problem came from the Pix.
That was not difficult to figure out : it had some protocol inspector activated for SMTP :
$ sh ru [...] fixup protocol smtp 25 [...]Just after :
> no fixup protocol smtp 25… it started to work perfectly well !!!
The engine for the SMTP protocol could not recognize the TLS handshake, considered that the SMTP session as not valid and therefore blocked it !
I can deactivate it without any fear as my Postfix server is already pretty well secured, or at least configured to reject any weired SMTP dialog.