Re: SSL, 'plain text' encoding, no cert

From: Michael Amling (nospam_at_nospam.com)
Date: 03/10/04 

Date: Wed, 10 Mar 2004 12:52:48 GMT

David Wagner wrote:
> Does anyone know anything about this? SANS reports a claim that
> it's possible for rogue SSL sites without a valid certificate to
> bypass the warning message that usually pops up in such a situation,
> by using a 'plain text' encoding (whatever that means):
>
> "One of the SSL encoding methods is "plain text". Most SSL servers have
> this disabled by default, but most browsers support it. When plain
> text is used, no central certificate authority is consulted and the
> user never sees a message asking if a certificate should be accepted
> (because "plain text" doesn't use certificates). Keeping that in mind,
> the little lock icon may not even indicate an encrypted channel. The
> little lock only indicates an SSL connection."
> http://isc.sans.org/diary.html?date=2004-03-04
>
> Does anyone have any idea what they're talking about? I thought
> I knew SSL fairly well, but I'm not familiar with the "plain text"
> encoding, so apparently I don't know it as well as I thought.

   In Netscape 7, follow Preferences : Privacy & Security : SSL : Edit
Ciphers and look around to find checkboxes for "No encryption with RSA
authentication and a SHA1 MAC" and "No encryption with RSA
authentication and an MD5 MAC". This is the same place you'd go to turn
off the checkboxes for 40-bit and 56-bit encryption. AFAIK, other
browsers do not allow this level of control over SSL.
   To determine whether the lock icon appears, you'd need to find a
server that supports one of the "No encryption" options.

   The fact that "no encryption", 40-bit and 56-bit ciphers are even
options is the number one reason I prefer my own protocol to SSL. SSL is
too configurable for its own good.
   Number two is the trusted CA certificate distribution problem. The
security of SSL depends on the the assumption that the CA certificate
list was securely downloaded and has remained unchanged since then, an
assumption that is to my knowledge never checked. And in that long list
of CAs, how many are fronts? The browser doesn't notify the user if one
day a site presents a certificate signed by Thawte, and the next day
mysteriously presents a certificate signed by NSAFront. Getting an entry
in the CA list is what allows that one firewall whose name escapes me to
act as an SSL man in the middle, decrypting all traffic in both directions.
   Number three is that SSL sends too much in the clear. Triangle Boy
was doomed, if for no other reason, by the fact that bytes n..n+m in the
TCP stream from the server to the browser were always a certain name in
a certain certificate transmitted in the clear.

--Mike Amling

Relevant Pages