Hacker News Reader

Comment by mustpax | Hacker News Reader

When intercepting a regular HTTP session Silk is no more of a MITM attack than any ISP out there. I trust Amazon more than I trust AT&T or Verizon.

What disturbs me is that Amazon Silk will terminate SSL on their end by default.* This is the break from the past that's worrisome.

* Source: http://www.amazon.com/gp/help/customer/display.html/ref=hp_l...

View on HN

"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."

Between your device and that site doesn't sound like terminating at AWS. Also, the SPDY connection to AWS is secure which gets you a leg up on sites that aren't using SSL.

By terminate I mean Amazon's doing the SSL certificate verification on AWS and reestablishes a new connection (with SPDY) that they themselves sign. In this case, Amazon will be free to read and modify all data in flight, defeating the whole purpose of HTTPS.

"We will establish a secure connection from the cloud to the site owner on your behalf for page requests of sites using SSL."

read the sentence right above that: "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://example.com)." that means that the SSL is terminated at amazon's servers, they see it in plaintext, then they send it via SPDY (re-encrypted) to your device. so it is always secure over the wire, but is plaintext readable by amazon. if you are worried about what someone on the wire can see, you are good. if you are worried about what amazon can see, you're not.

Let's not forget that this decryption and re-encryption[1] is going on in the AWS cloud, which is ostensibly shared infrastructure. Its not just what Amazon can see, but what other people who happen to be running on the boxes doing this re-encryption can see (through security vulnerabilities).

[1] I'm making the assumption here that re-encryption is actually occurring. It could be the case that its not and the phrasing was simply poor.

Yeah, that's what I find worrisome as well.

And I don't see how it's possible for them to proxy SSL content without being MITM and re-encrypting. They could stay entirely out of the way for HTTPS requests, but if that's how they were doing it, I think their FAQ answer would just say so. If, on the other hand, they're inline enough to do the Silk acceleration thing at all, they have to be able to decrypt the traffic.

As others pointed out, that is at odds with the previous paragraph ("We will establish a secure connection from the cloud to the site owner on your behalf").

Also, unless they stop doing the Silk combining thing entirely, I don't see how it's possible not to peer inside the requests. They can either pass along the traffic without knowing what it is (meaning they can't cache, or combine, requests or responses, because they don't know what's in those requests and responses), or they have to see inside.

This, to me, means they're taking liberties with the meaning of "direct connection" in the snippet you quoted, and, if I'm being pedantic, I don't see how the final sentence ("Any security provided ... would still exist") is literally true at all. Seems to me that being end to end, encrypted by a key only you and the other end, know, is a form of security that does not still exist in this architecture.

(Somewhat off topic, but when using earlier-generation Kindles with whispernet 3G, over 3G, all traffic is proxied through Amazon's datacenters, even for SSL, and I have no idea if it's secured end-to-end all the way to the device, or decrypted in Amazon's datacenter, and possibly re-encrypted to send OTA to the device. There's no way to tell.)

Reply on news.ycombinator.com