Re: Adding Security Considerations regarding interception to p1

So accordingly, how would you feel with the following changes?

1. Remove the sentence:
"Use of TLS [RFC2818] can mitigate such passive interception attacks."

2. Remove the sentence:
"Encryption [RFC2818] may or may not mitigate this form of attack, depending 
on the client and individual behaviors."

Or add the following before that sentence:
"This is because, without client and server authentication, a client 
generally has no way of knowing that it is indeed communicating with the 
correct server and vice versa."

3. Change the last sentence to:
"Nevertheless, servers ought to carefully consider the privacy implications 
of using HTTP without encryption and the security implications of not using 
client and server authentication."

And perhaps mention certificates in that last sentence.

--Peter

-----Original Message----- 
From: Willy Tarreau
Sent: Wednesday, September 18, 2013 4:09 PM
To: Mark Nottingham
Cc: IETF HTTP WG
Subject: Re: Adding Security Considerations regarding interception to p1

Hi Mark,

[...]

While the text seems well balanced, I still fear that is will promote
clueless deployment of TLS which will only make things worse by fooling
users into thinking they're protected.

I've worked as a consultant for a bank for 14 years, and regularly heard
the same thing : use SSL/TLS to secure a communication channel. Fortunately
a few guys *knew* it would provide nothing if the client did not check the
certs. And that situation is extremely common. Browsers, wget, curl do
verify certs. Users bypass the checks when they get an error. And other
tools (many web service clients for example) do not even check the certs.
But these deployments look safe because they're done over TLS.

I've been used to do some demos using a 2-port guruplug server setup in
bridge with haproxy running in SSL-clear-SSL mode and transparently
deciphering and reciphering traffic. You'd be amazed at the number of
devices and software which don't complain. Some SIP phones do not detect
my trivial man-in-the-middle capture device. Even some smartphone apps
connect seamlessly over WiFi this way. Thus I'd rather not promote a
blind TLS deployment when people have no clue what they're doing.

So I'd be either for not adding the text or trying to educate admins
further and not giving them any direction but only the risks so that
they look for information by themselves. Maybe removing the last
paragraph would be enough to avoid blind deployments, I don't know.

Best regards,
Willy

Received on Wednesday, 18 September 2013 22:01:27 UTC