Re: Adding Security Considerations regarding interception to p1

Hi Mark,

On Wed, Sep 18, 2013 at 11:30:27AM +1000, Mark Nottingham wrote:
> Interception and Privacy
> 
> Common use of HTTP often contains a considerable amount of Personally Identifying Information; this might include cookies [RFC6265], application data, and even patterns of access.
> 
> If used without encryption, HTTP makes this data vulnerable to passive interception. There are known instances when third parties have exploited the in-the-clear nature of "http://" URIs to obtain sensitive information, for a variety of purposes. Use of TLS [RFC2818] can mitigate such passive interception attacks.
> 
> Moreover, like other clear text protocols, HTTP/1.1 is subject to an active man-in-the-middle attack.  That is, it is possible for an intermediary
> device to terminate a client TCP connection and respond as if it had the IP address of the intended HTTP server.  An attacker may insert or delete content or redirect the client to a completely different web site.  Encryption [RFC2818] may or may not mitigate this form of attack, depending on the client and individual behaviors. 
> 
> HTTP/1.1 does not make any particular security mechanism -- including encryption -- Mandatory to Implement, as its deployment pre-dated [RFC3631]. Nevertheless, servers ought to carefully consider the privacy implications of using HTTP without encryption (i.e., using TLS [RFC2818]), preferring its use where there is any potential for access to be considered sensitive. 

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 20:09:30 UTC