© 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

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

OpenSSL

Heartbleed

7April

2014

Heartbleed

What was the Heartbleed bug? TLS explained

Application protocol (HTTP, SMTP, SQL … )

SSL/TLS

TCP/IP

What was the Heartbleed bug? TLS record format

Message

type

Protocol

version

Record

lengthData

What was the Heartbleed bug? The Heartbeat

extension

Heartbeat: RFC6520

Message

type

Protocol

version

Record

lengthPadding

Heartbeat

message

type

Payload

length Payload

What was the Heartbleed bug?

What was the Heartbleed bug? Heartbeat

extension format

Message

type

Protocol

version

Record

lengthPadding

24 3.2 22

Heartbeat

message

type

Payload

length Payload

Padding1 3 0xBADBAD

What was the Heartbleed bug? Heartbeat

extension format

24 3.2 22 Padding1 0xBADBAD65535

Message

type

Protocol

version

Record

lengthPadding

Heartbeat

message

type

Payload

length Payload

What was the Heartbleed bug?

What was the Heartbleed bug? The code

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

Two lines of code

Heartbleed: The response

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

Heartbleed: The response

The Core Infrastructure Initiative founded

New research into vulnerability detection

LibreSSL project is started; iterates rapidly

BoringSSL project begins

The response: s2n

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

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.

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.

How we develop and test s2n

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

Team culture

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

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

s2n’s development principles

https://github.com/awslabs/s2n/blob/master/docs/DEVELOPMENT-GUIDE.md

Simple designs, readable code

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

Example code

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

Designing for safety: The stuffer

λInput λ λ Output

Decrypt Parse/respond

Encrypt

Designing for safety: the Stuffer

Nested branches

Nested branches

Straight line

Straight line

Quick, easy, and habitual

testing

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

Make tests fast

Make tests easy to write

Example code

Systematic defense in depth

Designing for safety

Designing for safety

Stream I/O: The stuffer

Start EndRead cursor Write cursor

data_available() space_remaining()

Designing for safety: The stuffer

Designing for safety: The stuffer

Verification

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

s2n verification

Where is s2n today

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

s2n today

Seven active Amazon contributors; bus-factor: 0

Contributions from 11 non-Amazonians

Used in production

~2.5% performance improvement

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

Thank you!

NET405

Remember to complete

your evaluations!

Related sessions

SEC401 - Automated Formal Reasoning About AWS

Systems

SAC306 - Encryption: It Was the Best of Controls, It

Was the Worst of Controls