[cryptography] yet another certificate MITM attack

Thierry Moreau thierry.moreau at connotech.com
Sun Jan 13 17:25:20 EST 2013


Jeffrey Walton wrote:
> On Sun, Jan 13, 2013 at 1:20 PM, Warren Kumari <warren at kumari.net> wrote:
>> On Jan 12, 2013, at 4:27 AM, ianG <iang at iang.org> wrote:
>>
>>> On 11/01/13 02:59 AM, Jon Callas wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> ...
>> The Amazon FAQ for Silk did at least say:
>> "We will establish a secure connection from the cloud to the site owner on your behalf for page requests of sites using SSL (e.g. https://siteaddress.com). Amazon Silk will facilitate a direct connection between your device and that site. Any security provided by these particular sites to their users would still exist."
>> while they were doing this.
>>
>> There was some flap, grumpiness about this, see for example: http://www.zdnet.com/blog/networking/amazons-kindle-fire-silk-browser-has-serious-security-concerns/1516
>>
> That's in contrast to my site's Terms of Service, which expressly forbids it.
> 
> NO UNLAWFUL INTERCEPTION
> 
> Software Integrity users expect end-to-end security. We prohibit
> proxying or interception of communication for any protocols or ports
> over any medium including, but not limited to, SSL/TLS, VPN, HTTP,
> HTTPS, SHTTP, SMTP, SSMTP, IMAP, IMAP4-SSL, IMAPS, POP, and SSL-POP,
> including electronic, analog or digital voice, analog or digital data,
> wired, wireless, and cellular.
> 
> Assuming one of these Interception Accelerators visited my site on
> behalf of a user, I believe that means they have exceeded their
> authority. Perhaps I should ask someone like Weev what happens to
> folks who do that (who was convicted of aggregating public data from a
> public service hung off a public internet). Should I press for a CFAA
> violation? Or should I ask for injunctive relief from the folks who
> destroy the secure channel?
> 

You may also request your users to authenticate with client digital 
signature keys (you maintain your own trusted database of client-public 
key relationships, as in the first party certification paradigm). Then 
the MITM agents will not be in a position to impersonate your users.

You will have to explain to the users who can't connect that some MITM 
agent was in their network path to your site. Maybe the security 
criticalness of your site deserves such a cryptographic control.

Sometimes controls stand in the way of those who put them in place. But 
cryptographic controls are meant to block traffic sometimes. I 
understand you don't tolerate any exception for well-intentioned MITM 
agents. At least this was the intent of those who developed the TLS 
protocol.

In HTML RFC2616 Security Considerations section:

15.7 Proxies and Caching

    By their very nature, HTTP proxies are men-in-the-middle, and
    represent an opportunity for man-in-the-middle attacks. Compromise of
    the systems on which the proxies run can result in serious security
    and privacy problems. Proxies have access to security-related
    information, personal information about individual users and
    organizations, and proprietary information belonging to users and
    content providers. A compromised proxy, or a proxy implemented or
    configured without regard to security and privacy considerations,
    might be used in the commission of a wide range of potential attacks.

    Proxy operators should protect the systems on which proxies run as
    they would protect any system that contains or transports sensitive
    information. In particular, log information gathered at proxies often
    contains highly sensitive personal information, and/or information
    about organizations. Log information should be carefully guarded, and
    appropriate guidelines for use developed and followed. (Section
    15.1.1).

That's a fair description of MITM minefield.

In TLS 1.0 RFC2246 sections F.1.1.1 and F.1.1.2 you will see that the 
TLS designers stated "server authentication is required in environments 
where active man-in-the-middle attacks are a concern" and explained how 
server authentication is effected.

Whether service agreements refer to these notions when they pretend to 
offer a secure connection could be argued in an arbitration forum, but 
this should be clear for the "experts" on this list.

Regards,

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691



More information about the cryptography mailing list