[cryptography] yet another certificate MITM attack

Ben Laurie ben at links.org
Mon Jan 14 06:04:11 EST 2013


On 14 January 2013 06:11, ianG <iang at iang.org> wrote:
> On 13/01/13 22:47 PM, 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.
>
>
>
> Well, I'm glad some see the penny drop on this one.
>
> The issue here is that Nokia have crafted an agreement by hook or by crook
> with the phone user.  But they have forgotten that an SSL connection is
> between the user and the site.
>
> An online bank is party to that.  If there is any difficulty, such as a
> phishing thing or even an insider attack at Nokia, then Nokia will be nailed
> to the cross in court.  They are screwed, legally, because they offered the
> deal but materially broke the contract.
>
> More particularly, banks will have a cause of action against their CA, which
> has not apparently batted an eye about the breach of the security model.
> Sure, so everyone is doing this.  Sure, so there is a really good
> optimisation argument.

How is any CA involved in this?

>
> Unfortunately, it broke the security assumptions.  SSL is so wedded to the
> point-to-point or client-to-server model that there is really no way around
> this.
>
> iang
>
>
>> 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?
>>
>> Jeff
>> _______________________________________________
>> cryptography mailing list
>> cryptography at randombit.net
>> http://lists.randombit.net/mailman/listinfo/cryptography
>>
>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography



More information about the cryptography mailing list