Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AWS re:Invent 2016: Amazon s2n: Cryptography and Open Source at AWS (NET405)

491 views

Published on

Launched in June of 2015, s2n is an AWS open-source implementation of the TLS and SSL network security protocols, which focus on security, simplicity, and performance. With development led by engineers from Amazon EC2, Amazon S3, Amazon CloudFront, and AWS security and cryptography services, s2n is a unique opportunity to observe how we develop and test security and availability for critical software at AWS. Learn how we iterate and code, how we automate software verification beyond the usual code reviews, and how open source works at Amazon.

Published in: Technology
  • My special guest's 3-Step "No Product Funnel" can be duplicated to start earning a significant income online. ★★★ https://bit.ly/2kS5a5J
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Stop getting scammed by online, programs that don't even work! ●●● https://tinyurl.com/y4urott2
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

AWS re:Invent 2016: Amazon s2n: Cryptography and Open Source at AWS (NET405)

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Colm MacCárthaigh December 1, 2016 NET405 Amazon s2n: Cryptography and Open Source at AWS
  2. 2. What to expect from the session Why s2n? A brief look at the OpenSSL Heartbleed bug Open source at AWS: How we started s2n How we develop and test s2n Where s2n is and our future plans
  3. 3. OpenSSL
  4. 4. Heartbleed 7 April 2014
  5. 5. Heartbleed
  6. 6. What was the Heartbleed bug? TLS explained Application protocol (HTTP, SMTP, SQL … ) SSL/TLS TCP/IP
  7. 7. What was the Heartbleed bug? TLS record format Message type Protocol version Record length Data
  8. 8. What was the Heartbleed bug? The Heartbeat extension Heartbeat: RFC6520 Message type Protocol version Record length Padding Heartbeat message type Payload length Payload
  9. 9. What was the Heartbleed bug?
  10. 10. What was the Heartbleed bug? Heartbeat extension format Message type Protocol version Record length Padding 24 3.2 22 Heartbeat message type Payload length Payload Padding1 3 0xBADBAD
  11. 11. What was the Heartbleed bug? Heartbeat extension format 24 3.2 22 Padding1 0xBADBAD65535 Message type Protocol version Record length Padding Heartbeat message type Payload length Payload
  12. 12. What was the Heartbleed bug?
  13. 13. What was the Heartbleed bug? The code
  14. 14. Contributing factors No good test cases Code is handling raw buffers with no systematic defense against overflows A lot of code in one file with a high cognitive load Needless functionality included by default
  15. 15. Two lines of code
  16. 16. Heartbleed: The response
  17. 17. Heartbleed: The Amazon response All services upgraded, without additional customer impact, within 16 hours of the Heartbleed issue Monitoring and notification process set up to detect impacted customer instances Customers do a great job: 80% updated within 5 days, 98% within one month
  18. 18. Heartbleed: The response The Core Infrastructure Initiative founded New research into vulnerability detection LibreSSL project is started; iterates rapidly BoringSSL project begins
  19. 19. The response: s2n
  20. 20. The response: s2n Core of s2n first came together within about 40 hours of development time over 5 weekends. First working connection at hour 30. Ben Laurie: “The really fun part of working on cryptography is spending hours staring at big opaque numbers and trying to figure out why they aren’t different big opaque numbers”.
  21. 21. The response: s2n Proposal to make s2n an official AWS project: Start with a “working backward” document. Initial feedback from customers: Sounds great! Make sure it’s open source. Initial feedback from AWS leadership: Sounds great; need to define long-term ownership and security process.
  22. 22. The response: s2n Path to open source: working with Amazon Open Source team, Amazon Legal. Very friendly, extremely helpful, and smooth process. Path to ownership: Several teams interested in participating. Define a “v-team” for s2n. Roadmap, on-call rotation, long term alignment. Path to a security process: Work with CISO and CEO.
  23. 23. How we develop and test s2n
  24. 24. Things to focus on 1. Team culture 2. Simple designs, readable code 3. Quick, easy, habitual testing 4. Systematic defense in depth 5. Verification of everything
  25. 25. Team culture
  26. 26. Starting s2n Agree and document goals, priorities, and tenets Agree and document our coding guidelines Make testing and safety easy and fast Think hard about the high-level design
  27. 27. s2n’s initial goals Build and maintain a world-class TLS implementation Raise the bar for testing, secure coding practices, and defense in depth Stay minimal, simple with safe defaults Write great code but stay humble and cautious
  28. 28. s2n’s development principles https://github.com/awslabs/s2n/blob/master/docs/DEVELOPMENT-GUIDE.md
  29. 29. Simple designs, readable code
  30. 30. s2n coding guidelines Focused on clean and consistent, readable code Include verbose comments to provide context and explain why we’re doing something; code itself should be self- documenting about what we’re doing Automate the code formatting
  31. 31. Example code
  32. 32. Simple designs, readable code Readable code > Less code > More code Avoid branches as much as possible Small, simple, discrete functions Split message parsing and flow control
  33. 33. Designing for safety: The stuffer λInput λ λ Output Decrypt Parse/ respond Encrypt
  34. 34. Designing for safety: the Stuffer
  35. 35. Nested branches
  36. 36. Nested branches
  37. 37. Straight line
  38. 38. Straight line
  39. 39. Quick, easy, and habitual testing
  40. 40. Quick, easy, and habitual testing Make tests easy enough for interns to write in their first week Testing is a habit, like brushing your teeth Make running tests fast Automate the end-to-end testing
  41. 41. Make tests fast
  42. 42. Make tests easy to write
  43. 43. Example code
  44. 44. Systematic defense in depth
  45. 45. Designing for safety
  46. 46. Designing for safety
  47. 47. Stream I/O: The stuffer Start EndRead cursor Write cursor data_available() space_remaining()
  48. 48. Designing for safety: The stuffer
  49. 49. Designing for safety: The stuffer
  50. 50. Verification
  51. 51. s2n verification Six formal code audits; government and commercial Automated formal verification of undefined behavior, HMAC correctness, RNG correctness, core state machine Automated fuzz testing with AFL and libFuzzer In-progress work on automated side-channel verification
  52. 52. s2n verification
  53. 53. Where is s2n today
  54. 54. s2n today Still focused on the server side; beginning now on client side No support for many features, including client certificates (now in progress) SSLv3, 3DES disabled in response to published research
  55. 55. s2n today Seven active Amazon contributors; bus-factor: 0 Contributions from 11 non-Amazonians Used in production ~2.5% performance improvement
  56. 56. Key takeaways Write goals, development principles, code guidelines Value clear and concise, readable code Make testing easy, fast, and habitual Formal verification is getting easier quickly
  57. 57. Thank you! NET405
  58. 58. Remember to complete your evaluations!
  59. 59. Related sessions SEC401 - Automated Formal Reasoning About AWS Systems SAC306 - Encryption: It Was the Best of Controls, It Was the Worst of Controls

×