veyepar: libtls: Rethinking the TLS/SSL API

Author(s):	Joel Sing
Location	Wellington Room 1
Date	jan Thu 19	Days Raw Files
Start	20:20	First Raw Start	20:10
Duration	0:45:0	Offset	0:09:30
End	21:05	Last Raw End	21:10
Chapters	00:00 0:20:03
Total cuts_time	44 min.

http://linux.conf.au/schedule/presentation/27/
raw-playlist raw-mp4-playlist encoded-files-playlist host archive tweet mp4 svg png

assets release.pdf libtls_Rethinking_the_TLSSSL_API.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

As anyone who has written code that implements a TLS client or server will know,
many of the existing APIs (namely OpenSSL) are confusing, difficult to use and
full of pitfalls for the unwary. Many security issues (and less serious bugs)
are due to the mistakes made by human developers, while trying to navigate their
way through the various function calls, return codes and missing functionality.

libtls is a component of the [LibreSSL project](http://www.libressl.org/); a
project that started as a fork of OpenSSL following the infamous
[heartbleed](http://www.heartbleed.com/) incident. While the general goals for
LibreSSL are to modernise the codebase, improve security, and apply best practice
development processes, libtls aims to completely rethink the TLS API.

This talk will cover some of the many issues with existing TLS/SSL APIs, prior
to looking at how libtls has been designed to be different. The history of libtls
will be discussed, before detailing the API development process that has been
used, which has allowed the library to morph and improve over time. The set of
rules that have been put in place to ensure that the API is as developer friendly
as possible will be explained, followed by a discussion of the overall litmus
test and proving ground that has been used during its design and development.

Comment:

production notes