Re: Adding Security Considerations regarding interception to p1

What Roy, Will, and Werner have said.

I felt the same way yesterday, but they have expressed it much better.

Regards,   Martin.

On 2013/09/19 5:09, Willy Tarreau wrote:
> 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 Thursday, 19 September 2013 01:42:55 UTC