SSL, 'plain text' encoding, no cert
David Wagner
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.
Paul Rubin
> 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.
That looked pretty weird to me too. SSL does support a cipher suite
where there's no encryption (just MAC) but that suite still uses
certificates. It's also disabled in most browsers. You have to turn
it on through a preferences dialog if you want to use it.
Roger Schlafly
> That looked pretty weird to me too. SSL does support a cipher suite
> where there's no encryption (just MAC) but that suite still uses
> certificates. It's also disabled in most browsers. You have to turn
> it on through a preferences dialog if you want to use it.
But if you turn it on, then the browser shows a padlock without
any root cert checking? It doesn't make sense to me.
Hyper4S
news:7xsmghq...@ruckus.brouhaha.com...
> That looked pretty weird to me too. SSL does support a cipher suite
> where there's no encryption (just MAC) but that suite still uses
> certificates. It's also disabled in most browsers. You have to turn
> it on through a preferences dialog if you want to use it.
You're talking about the "TLS_RSA_WITH_NULL_MD5/_SHA" ciphersuites,
providing a digest (MAC) and server authorization (by certificate) but no
encryption.
The article however is referring to the "Anonymous DH ciphersuites"
("TLS_DH_anon_..."), I guess.
Those provide encryption and digest, but no server authorization (no
certificate).
To test the "most browsers support this"-hypothese, I quickly set up an
openssl server("openssl s_server -accept 443 -nocert -www"), using no
certificates (indicated by the "-nocert" option, which restricts the
ciphersuites to the anonymous DH ones).
However, I wasnt able to connect to it, not with IE 6.0, nor with Netscape
7.1, because they had "no shared cipher".
I havent tested any other browser, but I have no reason to believe that they
would behave differently...
Grtz,
Kristof
Peter Gutmann
The details are pretty confused, mostly because the online stories are all
repeating (or at least paraphrasing) each other. The ZDNet story:
In that case the scam's designers used encrypted SSL conections to direct
users to their site but fraudulent certificates to persuade victims they
were in the right place.
sounds like it's referring to a cert for a site that outsources its hosting to
a third party. This is very common, and browsers don't warn about it because
it'd scare users away from half the sites on the net if they did.
The other part of the story:
"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."
presumably refers to NULL_WITH_NULL, so the scammer configures the server to
ask for this cipher suite, which is the initial suite (that is, you're in the
NULL_WITH_NULL state before you start the SSL handshake). So the browser
doesn't perform any further negotiation, but just displays the lock icon since
it's already in the requested state. Kinda surprising that any implementation
would do this though, both because the spec says you should never do this and
because you'd need to add special-case code to allow this behaviour, it's not
just some default you can fall back to without thinking about it.
Peter.
Michael Amling
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
Grumble
Netcraft posted an article:
http://news.netcraft.com/archives/2004/03/08/ssls_credibility_as_phishing_defense_is_tested.html
--
Regards, Grumble
Hyper4S
"Michael Amling" <nos...@nospam.com> wrote in message
news:AcE3c.32344$PY.1...@newssvr26.news.prodigy.com...
> Number three is that SSL sends too much in the clear.
Could you elaborate on that one?
I know the SSL handshake is unencrypted, but its integrity is checked
afterwards in the encrypted Finished messages, before any sensitive data has
been sent.
This "integrity check" seems waterproof to me (at least if the cryptographic
parameters negotiated are secure).
What problems do you see with this "clear text" handshake? (I suppose you
were referring to the handshake)
Grtz,
Kristof
Hyper4S
news:AcE3c.32344$PY.1...@newssvr26.news.prodigy.com...
> 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.
I set up such a server (openssl s_server -cipher NULL_SHA), and tested it
with a reconfigured Netscape 7.1 (to accept this kind of unencrypting
ciphersuites).
It accepts the connection (of course), but shows a *broken* lock icon, on a
red surface. When clicking on that icon for more info, it warns that there
is currently no encryption enabled.
Nice behaviour :-)
I cant get IE6 to accept this sort of connections, because it isnt
configurable in such a detailed way, as pointed out. However, not accepting
this sort of connections at all seems a good thing to me :-)
Grtz,
Kristof
Paul Rubin
> What problems do you see with this "clear text" handshake? (I suppose you
> were referring to the handshake)
It makes traffic analysis easier. SSL wasn't designed to prevent that.
It's quite hard to do anything about it with an SSL-like protocol.
David M
> 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):
There's a pretty good explanation of what is really going on here:
http://www.rtfm.com/movabletype/archives/2004_03.html#000792
-David (sleepy)
Henrick Hellström
Not necessarily: The problem is to hide the client identity if client
authentication is required. The solution is to perform two consecutive
handshakes - the first in the clear with server authentication and no
client authentication, and the second encrypted with the session key
from the first and with both server and client authentication.
David Wagner
Ok, it sounds like ekr is basically saying that Neal Krawetz / SANS are
blowing hot air (when it comes to this 'plain text' encoding business)
and there's nothing new to worry about here (there is no such 'plain text'
vulnerability in today's browsers, when run with default configurations).
Good, that fits better with my mental model of how today's browsers
implement SSL. Thanks for the pointer.
Paul Rubin
> > It makes traffic analysis easier. SSL wasn't designed to prevent
> > that. It's quite hard to do anything about it with an SSL-like
> > protocol.
>
> Not necessarily: The problem is to hide the client identity if client
> authentication is required.
You really want to hide the identity of both sides. I don't see any
simple way to do that.
Henrick Hellström
> You really want to hide the identity of both sides. I don't see any
> simple way to do that.
If the only security problem is with the name information in the
certificates, the solution is technically easy: Use a restricted in
house CA and let it issue two certificates for each public key; one with
subject name information and one without. Use the certificate without
name information for the SSL handshake and transmit the one with name
information during the secure session. Obviously, this solution rests on
the assumption that the server is willing to trust anyone with a client
certificate issued by any of the CAs the server trusts.
Paul Rubin
> If the only security problem is with the name information in the
> certificates, the solution is technically easy: Use a restricted in
> house CA and let it issue two certificates for each public key; one
> with subject name information and one without. Use the certificate
> without name information for the SSL handshake and transmit the one
> with name information during the secure session.
How do you stop the eavesdropper from seeing the public key in the
certificate without name information? If the public key is re-used in
different sessions, that uniquely identifies the user. The user could
get a big stack of certs from the CA and use a new one for every
session, but that's not what we normally think of as a public key
system.
Henrick Hellström
> How do you stop the eavesdropper from seeing the public key in the
> certificate without name information? If the public key is re-used in
> different sessions, that uniquely identifies the user. The user could
> get a big stack of certs from the CA and use a new one for every
> session, but that's not what we normally think of as a public key
> system.
I believe some problems can't be solved. The client will anyway have to
include the IP address and port number of the server in the transmission
packets - at least unless a tunnel is used, but then the entity
operating the tunnel would have to be trusted with this information.
Michael Amling
1. It makes it obvious to whom the client is connecting. Search the
web for "Triangle Boy" for an example of when that's not desired.
2. It makes the public key obvious. I will admit this is the most
minor of quibbles. While I doubt 1024-bit RSA keys are being factored
outside NSA, ...
And the number Four reason I prefer my protocol to SSL is: forward
secrecy, which SSL may be capable of, but just ain't happening when my
browser connects to paypal.com (or to JLC's imitation thereof).
--Mike Amling
Hyper4S
> 1. It makes it obvious to whom the client is connecting. Search the
> web for "Triangle Boy" for an example of when that's not desired.
I found a paper
(http://www.usenix.org/events/sec02/full_papers/martin/martin.pdf)
about privacy-issues concerning SafeWeb (which uses Triangle Boy),
but as far as I understand that paper, the problems discussed there have
nothing to do with SSL.
However, I get your point that the identity of the server should be hidden,
in the ideal case.
> 2. It makes the public key obvious. I will admit this is the most
> minor of quibbles. While I doubt 1024-bit RSA keys are being factored
> outside NSA, ...
Thats what public keys are after all, "public" :-)
> And the number Four reason I prefer my protocol to SSL is: forward
> secrecy, which SSL may be capable of, but just ain't happening when my
> browser connects to paypal.com (or to JLC's imitation thereof).
Actually, what is that "my protocol" you keep referring to? Is it available
for download, or is it just something you developped for personal use? Or do
you use that term to refer to a "theoretically ideal SSL protocol"?
Grtz,
Kristof
Nelson B
> You really want to hide the identity of both sides. I don't see any
> simple way to do that.
Many servers do that now, almost automatically. The sequence of events is:
first handshake, no client auth requested, server auth only.
everything below this point is encrypted
client sends http request over ssl
server sees that the requested URL requires client authentication
server initiates second handshake, requesting client auth. This
entire handshake is encrypted in both directions
server sends response.
subsequent transactions reuse the negotiated "master secret" avoiding
the RSA overhead.
--
Nelson B
Paul Rubin
> > You really want to hide the identity of both sides. I don't see any
> > simple way to do that.
>
> Many servers do that now, almost automatically. The sequence of events is:
> first handshake, no client auth requested, server auth only.
The server certificate immediately reveals the server's identity! Oops!
EKR
wouldn't represent a real security problem here because you still do
the SSL handshake. So, the attacker would need to convince the user to
accept their certificate in order to downgrade you to NULL_MD5 (the
negotiation is protected in SSLv3 and TLS). And if they can do that,
why bother with negotiating a NULL algorithm, since the client is
about to send their private information encrypted with a key the
attacker knows!
-Ekr