4 ms·

I worked with EFS but not lambda in 2017-2018 when migrating an app to AWS - an app which included a bunch of random application code that assumed it could read

by shoo 6y ago

I worked with EFS but not lambda in 2017-2018 when migrating an app to AWS - an app which included a bunch of random application code that assumed it could read or write into a network file system. Having EFS as a migration target to replace on prem CIFS was relatively pleasant, which removed the need to rewrite a bunch of the application code. S3 would have been a reasonable replacement but that would have required weeks or months of rewrites to hunt down filesystem calls and rework them to use simpler object store API. One thing that tripped us up at the time was EFS not supporting encryption in transit: but this was fixed in early 2018 when EFS began supporting using stunnel to wrap the underlying NFS connection in TLS. https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html https://docs.aws.amazon.com/efs/latest/ug/encryption-in-tran... It reads as if this lambda integrated EFS works out of the box with encryption in transit

twoodfin 6y ago
I’m genuinely curious about the factors that made it OK to have an unencrypted protocol into 2018. Is the AWS infrastructure already encrypting at another layer? Nobody worries about attacks on data that’s only transiting AWS?
- cldellow 6y ago
  I think Google's internal network was unencrypted in 2013 [1], allowing the NSA to tap it. After the Snowden leaks showed that they were being tapped, Google moved to encrypting data on their internal links. I wouldn't be surprised if Amazon made a similar decision. [1]: https://blog.encrypt.me/2013/11/05/ssl-added-and-removed-here-nsa-smiley/ https://blog.encrypt.me/2013/11/05/ssl-added-and-removed-her...
  - twoodfin 6y ago
    Right, but this is in the context of AWS, where Amazon has got thousands of customers running their own code in its data center. I'd (naively?) assumed that any novel protocols to ship data back and forth between hosts in that environment would have been built on TLS from day 1.
- staticassertion 6y ago
  AWS has stated that internal traffic, at least within a VPC, is "tamper proof". I don't recall any specific details about that, whether it is the case across regions, accounts, etc.
  - shoo 6y ago
    back when i was working on this (for a large org) they regarded anything in AWS as fundamentally lower trust than their own on-premises corporate networks, so there was a security requirement to do encryption in transit for all TCP connections -- this was for an application within the VPC with no public traffic
    - staticassertion 6y ago
      It's gonna depend on your threat model ultimately. Hard to imagine running on AWS if you don't trust them though.
      - twoodfin 6y ago
        It's not so much about trusting AWS not to pry into your data. More that the attack surface of your data as presented to AWS' other—potentially hostile—customers is (presumably) significantly reduced by not having the bytes flying around AWS' infrastructure in the clear. To put it mildly, Amazon has a lot more folks a lot smarter than me thinking about these tradeoffs, so I assume they had good reason to think it was fine the first time around. I'm just surprised that the state-of-the-art for cloud-hosted services doesn't presume building on TLS from day 1, so I'd love to know what those reasons are.

by shoo 6y ago

twoodfin 6y ago

I’m genuinely curious about the factors that made it OK to have an unencrypted protocol into 2018. Is the AWS infrastructure already encrypting at another layer? Nobody worries about attacks on data that’s only transiting AWS?

cldellow 6y ago
I think Google's internal network was unencrypted in 2013 [1], allowing the NSA to tap it. After the Snowden leaks showed that they were being tapped, Google moved to encrypting data on their internal links. I wouldn't be surprised if Amazon made a similar decision. [1]: https://blog.encrypt.me/2013/11/05/ssl-added-and-removed-here-nsa-smiley/ https://blog.encrypt.me/2013/11/05/ssl-added-and-removed-her...
- twoodfin 6y ago
  Right, but this is in the context of AWS, where Amazon has got thousands of customers running their own code in its data center. I'd (naively?) assumed that any novel protocols to ship data back and forth between hosts in that environment would have been built on TLS from day 1.
staticassertion 6y ago
AWS has stated that internal traffic, at least within a VPC, is "tamper proof". I don't recall any specific details about that, whether it is the case across regions, accounts, etc.
- shoo 6y ago
  back when i was working on this (for a large org) they regarded anything in AWS as fundamentally lower trust than their own on-premises corporate networks, so there was a security requirement to do encryption in transit for all TCP connections -- this was for an application within the VPC with no public traffic
  - staticassertion 6y ago
    It's gonna depend on your threat model ultimately. Hard to imagine running on AWS if you don't trust them though.
    - twoodfin 6y ago
      It's not so much about trusting AWS not to pry into your data. More that the attack surface of your data as presented to AWS' other—potentially hostile—customers is (presumably) significantly reduced by not having the bytes flying around AWS' infrastructure in the clear. To put it mildly, Amazon has a lot more folks a lot smarter than me thinking about these tradeoffs, so I assume they had good reason to think it was fine the first time around. I'm just surprised that the state-of-the-art for cloud-hosted services doesn't presume building on TLS from day 1, so I'd love to know what those reasons are.