[cryptography] yet another certificate MITM attack

ianG iang at iang.org
Mon Jan 14 01:11:05 EST 2013


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.

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
>




More information about the cryptography mailing list