On 14 January 2013 06:11, ianG <[email protected]> wrote: > On 13/01/13 22:47 PM, Jeffrey Walton wrote: >> >> On Sun, Jan 13, 2013 at 1:20 PM, Warren Kumari <[email protected]> wrote: >>> >>> >>> On Jan 12, 2013, at 4:27 AM, ianG <[email protected]> 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 >> [email protected] >> http://lists.randombit.net/mailman/listinfo/cryptography >> > > _______________________________________________ > cryptography mailing list > [email protected] > http://lists.randombit.net/mailman/listinfo/cryptography _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
