emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.


From: Florian Weimer
Subject: Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.
Date: Sun, 26 Oct 2014 13:45:01 +0100

* Lars Magne Ingebrigtsen:

> Florian Weimer <address@hidden> writes:
>
>> Uhm, if this happens, the server has been downgraded.  The handshake
>> will fail if a man-in-the-middle attempts to force the use of SSL 3.0,
>> and both ends support something newer.  (As far as I can tell, Emacs
>> does not implement the vulnerable protocol downgrade code, unlike
>> browsers.)
>
> Oh.  Than what's all this fuss about, then?  Just the normal churn of
> "security professional" drama?

It's unusual in the sense that the actual vulnerability in SSL 3.0 was
fixed by subsequent protocol versions, beginning in 1999, and
surprisingly few were eager to point this out.  (It doesn't help that
for non-technical reasons, what should have been SSL 3.1 is now called
TLS 1.0.)

I have no good explanation why browser vendors are so wedded to their
broken fallback behavior.  Even if you assume that they are balancing
the their users' security needs and those of law enforcement agencies,
some communications still do not make sense.

Unfortunately, the early industry consensus (defined by those who were
in the original pre-disclosure circle) appears to have been to claim
that this fallback behavior is desirable, although it was never
standardized by the IETF, and not implemented in most (any?)
cryptographic libraries.  But that secret circle failed to do their
job properly, and their favorite remedy (TLS_FALLBACK_SCSV) is not
available in most released TLS implementations and major TLS-using
applications.  As a result, a “critical SSL vulnerability” hit the
news, and security-conscientious operators had literally no option at
hand to protect their user base, as it existed at that time (and not
much has changed in the few weeks since then).

Rather than admit to this failure and re-evaluate the browser fallback
behavior (or the claimed impact of the well-known SSL 3.0
vulnerabilities), the message turned into “disable SSL 3.0”, which is
something that is doable today with some effort.  (Some people even
prefer cleartext over SSL 3.0 encryption, which is rather bizarre, but
an understandable result of the situation.)  But considering that the
cryptographic libraries automatically upgrade away from SSL 3.0—if you
(as an application programmer) let them do their job, this step is
rather pointless busywork.  This effort only detracts from more
important work, such as enabling encryption (with proper
authentication, preferably) for additional services.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]