Re: Adding Security Considerations regarding interception to p1

On Wed, Sep 18, 2013 at 05:52:44PM -0400, Peter Occil wrote:
> 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.

It could probably be more exact with a mix of all that, but then does
it really provide any value to the existing document ?

I'd rather go with something much more generic in fact, like the following
idea :

"HTTP/1.1 is used for virtually every communication over the Internet today
 and as such is the target of many attacks :
  - passive interception attacks : the protocol is transported in clear text
    and may be passively intercepted by any party. This weakness has recently
    been magnified by the wide deployment of WiFi networks. Encryption may
    help reduce these risks if properly implemented.

  - active interception attacks (man in the middle) : the protocol offers no
    authentication of both ends, making it sensible to transparent proxying,
    which is used by many internet service providers to deliver cached contents
    and may be used by attackers to modify the traffic on the fly. Encryption
    with end-to-end authentication may help reduce these risks if properly
    implemented.

  - server-side attacks : log files may contain a lot of sensible information
    and are the target of some break-in attempts. Contents are also modified
    by attackers to deliver malware to many end users. These attacks are not
    related to the protocol but to its implementations and its wide deployment.

  - proxy-side attacks : corporate proxy logs are generally accessible to a
    few people who are in contact with the end users. Accessing these logs
    can become a privacy concern if browsing habits are disclosed among
    coworkers.

  - client-side attacks : malware running in browsers retrieve all contents
    in clear text before they leave the browser, and modify responses before
    they're displayed to the user. This is widely used to attack bank accounts
    and is not related to the protocol but to its implementations and its wide
    deployment.

Implementors should be aware of these threats and consider them carefully when
designing a new implementation. Encryption only solves the transport issue
between trusted parties if reciprocal authentication is enforced, but does
not address the security of the end points themselves. Logs are required to
address technical issues but should not reveal too much information. Agents
should disclose the least possible information about the users and only when
absolutely needed, as these information may still end in a network capture
or log file somewhere.
"

Willy

Received on Thursday, 19 September 2013 05:39:30 UTC