[Pitch] Cross-platform Swift TLS library


(Gelareh Taban) #1

Hi all,

I’d like to pitch some of the ideas that have been discussed in the server
working group around security.

To get more information on the server API group and its goals, see
https://swift.org/server-apis/. (TL;DR version is to come up with a set of
foundational APIs that work cross-platform, on all platforms supported by
Swift, including Linux.)

For security, we have divided the scope into SSL/TLS support and crypto
support. Our first goal and the subject of this pitch is TLS. This current
pitch is the result of various discussions that have taken place over the
past several months over the server working group mailing list and several
projects by groups such as Vapor, IBM, Zewo, etc.

Our plan is to start with the main ideas presented here and work on a Swift
library that we prototype and iterate on before finalizing on a specific
interface. Hopefully the ideas in this pitch are non-controversial, aside
from the naming of the method and protocols (which is widely accepted as a
`hard` problem).

# Problem

Since there is currently no standard Swift SSL/TLS library that is
compatible on both Apple and Linux, Swift projects use their TLS library of
choice (such as OpenSSL, LibreSSL, Security framework, etc). This results
in:
- fragmentation of the space as well as incompatibility of project
dependencies if more than one security package is needed by different
modules (a project cannot have both OpenSSL and LibreSSL in its dependency
graph)
- insecurity (using an unpatched or deprecated library such as OpenSSL on
macOS)
- unmaintainablity (using non-standard or non-native libraries)
- more complex code (using different APIs or code paths for each platform).

So we want to propose a standard set of protocols that define the behavior
of the TLS service and how the application and the server and networking
layers beneath it interact with the TLS service. What complicates this
pitch is that the Swift in server space is new and none of the interfaces
have yet been defined, so this is really a work in iteration.

# Design goals

We came up with the following design goals for a solution:

- Provide a consistent and unified Swift interface so that the developer
can write simple, cross-platform applications;
- Don't implement new crypto functionality and instead use existing
functions in underlying libraries;
- Plug-n-play architecture which allows the developer to decide on
underlying security library of choice, e.g., OpenSSL vs LibreSSL;
- Library should be agnostic of the transport mechanism (e.g., socket,
etc), whilst allowing for both blocking and non-blocking connections;
- Developers should be able to use the same TLS library for both client and
server applications.

# Proposal

The proposed solution basically defines a number of protocols for each
interface:
- Transport management
- TLS management

A basic diagram that shows the relationship between the proposed protocols
is shown below:

(See attached file: TLSServiceArchitecture.png)

![alt text](
https://raw.githubusercontent.com/gtaban/blogs/master/TLSServiceArchitecture.png
"Architecture of TLSService modules")

The transport management protocol essentially would be a combination of a
connection object (e.g., a socket pointer, a file descriptor, etc) and a
connection type.

This is the connection object that gets passed to the implementation of the
TLS service protocol, which also handles the read and write callbacks to
the connection object.

The TLS service protocol would define a sets of methods that deal with TLS
setup (certificates, server/client, etc), and TLS events (such as receiving
data, encrypting and writing to connection object or reading from a
connection object, decrypting and returning the data).
These methods are implemented by the TLS service which in turn uses its
choice of underlying security library. As an example, the TLS service uses
SecureTransport library on Apple platform and OpenSSL on Linux.

## How this would work

If an application requires TLS for its use case, it creates a TLS service
object and configures it based on its requirements.

The application then passes the TLS service object to its lower level
frameworks that deal with networking and communication. Each lower level
framework maintains an optional instance variable of type TLS service
protocol. If the optional variable exists, it is further passed down until
it gets to the lowest level that deals with the Swift transport layer APIs
(in the diagram above, this is the HTTP Management layer). When this layer
creates the connection using the transport layer APIs, it assigns the TLS
service object to the transport layer delegate. The Swift socket layer is
then responsible for calling the TLS service protocol methods that handle
the TLS functionality at the appropriate times.

# Source Compatibility:

As mentioned, the Swift in server space is still new and the interfaces are
currently under discussion. Although the proposed protocols are designed to
be as non-breaking as possible, they do place several assumptions on the
rest of the transport/application stack.

- The application layer must import and instantiate a TLS service object
which implements the TLS service protocol if it wants to enable TLS
service.
- Every framework layer above the transport management layer but below the
application layer (which includes HTTP and server frameworks) has an
optional object that implements the TLS service protocol. If the TLS object
exists, it is passed down to each layer below.
- The HTTP layer which sets up the transport management layer assigns the
TLS object to the transport management delegate if the object exists.
- The transport management layer which sets up the I/O communication
implements the transport management protocol.
- The transport management layer which sets up the I/O communication and
deals with the low level C system I/O, calls the appropriate TLS service
protocol methods whenever I/O data needs to be secured.
- The long term goal for the location of the TLS service protocol is within
the Foundation framework. In the short term, the protocol can live within
the transport management framework.


(Rien) #2

Having just finished a client/server framework that builds on openSSL I sympathise with this proposal.

However, I wrote a few blogposts about my experiences with openSSL. And those leads me to believe that there is not much interest in secure networking. The number of hits on those posts are quite low (anaemic even) when compared to -for example- posts on socket programming.

While the sketch you made below does not sound too bad, I am afraid that the API will become complex so fast, that it will not be much easier to use than openSSL/LibreSSL etc. But don’t let that stop you :wink:

Regards,
Rien

PS: https://github.com/Balancingrock/SecureSockets

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift

···

On 06 Apr 2017, at 18:16, Gelareh Taban via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I’d like to pitch some of the ideas that have been discussed in the server working group around security.

To get more information on the server API group and its goals, see https://swift.org/server-apis/. (TL;DR version is to come up with a set of foundational APIs that work cross-platform, on all platforms supported by Swift, including Linux.)

For security, we have divided the scope into SSL/TLS support and crypto support. Our first goal and the subject of this pitch is TLS. This current pitch is the result of various discussions that have taken place over the past several months over the server working group mailing list and several projects by groups such as Vapor, IBM, Zewo, etc.

Our plan is to start with the main ideas presented here and work on a Swift library that we prototype and iterate on before finalizing on a specific interface. Hopefully the ideas in this pitch are non-controversial, aside from the naming of the method and protocols (which is widely accepted as a `hard` problem).

# Problem

Since there is currently no standard Swift SSL/TLS library that is compatible on both Apple and Linux, Swift projects use their TLS library of choice (such as OpenSSL, LibreSSL, Security framework, etc). This results in:
- fragmentation of the space as well as incompatibility of project dependencies if more than one security package is needed by different modules (a project cannot have both OpenSSL and LibreSSL in its dependency graph)
- insecurity (using an unpatched or deprecated library such as OpenSSL on macOS)
- unmaintainablity (using non-standard or non-native libraries)
- more complex code (using different APIs or code paths for each platform).

So we want to propose a standard set of protocols that define the behavior of the TLS service and how the application and the server and networking layers beneath it interact with the TLS service. What complicates this pitch is that the Swift in server space is new and none of the interfaces have yet been defined, so this is really a work in iteration.

# Design goals

We came up with the following design goals for a solution:

- Provide a consistent and unified Swift interface so that the developer can write simple, cross-platform applications;
- Don't implement new crypto functionality and instead use existing functions in underlying libraries;
- Plug-n-play architecture which allows the developer to decide on underlying security library of choice, e.g., OpenSSL vs LibreSSL;
- Library should be agnostic of the transport mechanism (e.g., socket, etc), whilst allowing for both blocking and non-blocking connections;
- Developers should be able to use the same TLS library for both client and server applications.

# Proposal

The proposed solution basically defines a number of protocols for each interface:
- Transport management
- TLS management

A basic diagram that shows the relationship between the proposed protocols is shown below:

(See attached file: TLSServiceArchitecture.png)

![alt text](https://raw.githubusercontent.com/gtaban/blogs/master/TLSServiceArchitecture.png "Architecture of TLSService modules")

The transport management protocol essentially would be a combination of a connection object (e.g., a socket pointer, a file descriptor, etc) and a connection type.

This is the connection object that gets passed to the implementation of the TLS service protocol, which also handles the read and write callbacks to the connection object.

The TLS service protocol would define a sets of methods that deal with TLS setup (certificates, server/client, etc), and TLS events (such as receiving data, encrypting and writing to connection object or reading from a connection object, decrypting and returning the data).
These methods are implemented by the TLS service which in turn uses its choice of underlying security library. As an example, the TLS service uses SecureTransport library on Apple platform and OpenSSL on Linux.

## How this would work

If an application requires TLS for its use case, it creates a TLS service object and configures it based on its requirements.

The application then passes the TLS service object to its lower level frameworks that deal with networking and communication. Each lower level framework maintains an optional instance variable of type TLS service protocol. If the optional variable exists, it is further passed down until it gets to the lowest level that deals with the Swift transport layer APIs (in the diagram above, this is the HTTP Management layer). When this layer creates the connection using the transport layer APIs, it assigns the TLS service object to the transport layer delegate. The Swift socket layer is then responsible for calling the TLS service protocol methods that handle the TLS functionality at the appropriate times.

# Source Compatibility:

As mentioned, the Swift in server space is still new and the interfaces are currently under discussion. Although the proposed protocols are designed to be as non-breaking as possible, they do place several assumptions on the rest of the transport/application stack.

- The application layer must import and instantiate a TLS service object which implements the TLS service protocol if it wants to enable TLS service.
- Every framework layer above the transport management layer but below the application layer (which includes HTTP and server frameworks) has an optional object that implements the TLS service protocol. If the TLS object exists, it is passed down to each layer below.
- The HTTP layer which sets up the transport management layer assigns the TLS object to the transport management delegate if the object exists.
- The transport management layer which sets up the I/O communication implements the transport management protocol.
- The transport management layer which sets up the I/O communication and deals with the low level C system I/O, calls the appropriate TLS service protocol methods whenever I/O data needs to be secured.
- The long term goal for the location of the TLS service protocol is within the Foundation framework. In the short term, the protocol can live within the transport management framework.

<TLSServiceArchitecture.png>_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


#3

Hi Gelareh,

Overall I think this pitch is a great move forward.

I've found that this is already resulting in some incompatibilities trying to combine rather complex Swift projects. I recently worked on integrating Kitura-Net, which uses BlueCryptor as a wrapper over both CommonCrypto / OpenSSL. I was delighted by BlueCryptor, as it proved to be a somewhat drop-in replacement for my custom CommonCrypto overlay. Seeing that this pitch moves along the same lines, I'm all for.

Some inline comments below.

-Bouke

# Problem
Since there is currently no standard Swift SSL/TLS library that is compatible on both Apple and Linux, Swift projects use their TLS library of choice (such as OpenSSL, LibreSSL, Security framework, etc). This results in:
- fragmentation of the space as well as incompatibility of project dependencies if more than one security package is needed by different modules (a project cannot have both OpenSSL and LibreSSL in its dependency graph)
- insecurity (using an unpatched or deprecated library such as OpenSSL on macOS)

This is even more true for Homebrew which refuses to link OpenSSL as those links might confuse the OS to link to the system's library instead (which is even more outdated). There's quite a bit incorrect "advice" floating around on how to create those symlinks.

- unmaintainablity (using non-standard or non-native libraries)
- more complex code (using different APIs or code paths for each platform).

So we want to propose a standard set of protocols that define the behavior of the TLS service and how the application and the server and networking layers beneath it interact with the TLS service. What complicates this pitch is that the Swift in server space is new and none of the interfaces have yet been defined, so this is really a work in iteration.

# Design goals

We came up with the following design goals for a solution:

- Provide a consistent and unified Swift interface so that the developer can write simple, cross-platform applications;
- Don't implement new crypto functionality and instead use existing functions in underlying libraries;
- Plug-n-play architecture which allows the developer to decide on underlying security library of choice, e.g., OpenSSL vs LibreSSL;
- Library should be agnostic of the transport mechanism (e.g., socket, etc), whilst allowing for both blocking and non-blocking connections;
- Developers should be able to use the same TLS library for both client and server applications.

+1

Additionally I'd like to see and API that:

- is designed for "ease of use"
- is strong typed
- integrates well with Foundation (DispatchQueue)
- fosters good performance (threading)

# Proposal
(...)

I'm not deeply familiar with the topic, so no comments on this part.

···

On 2017-04-06 16:16:51 +0000, Gelareh Taban via swift-evolution said:


(Gelareh Taban) #4

Hi Rien,

This is great, thanks for referencing your blogs/repo. I'll go through
them.
(An unfortunate issue I have found with security is that, we need it, we
expect it, but we don't want to worry about it :slight_smile:

The basic structure of what we are considering right now would to a large
extent follow that of
https://github.com/IBM-Swift/BlueSSLService/
which invokes SecureTransport on Apple and OpenSSL on Linux.

For more details of some of the discussions, just follow this thread.
https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170320/000298.html

Would love to have your contributions here! :smiley:

gelareh

···

From: Rien <Rien@Balancingrock.nl>
To: Gelareh Taban/Austin/IBM@IBMUS
Cc: swift-evolution@swift.org
Date: 04/06/2017 11:54 AM
Subject: Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library

Having just finished a client/server framework that builds on openSSL I
sympathise with this proposal.

However, I wrote a few blogposts about my experiences with openSSL. And
those leads me to believe that there is not much interest in secure
networking. The number of hits on those posts are quite low (anaemic even)
when compared to -for example- posts on socket programming.

While the sketch you made below does not sound too bad, I am afraid that
the API will become complex so fast, that it will not be much easier to use
than openSSL/LibreSSL etc. But don’t let that stop you :wink:

Regards,
Rien

PS: https://github.com/Balancingrock/SecureSockets

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift

On 06 Apr 2017, at 18:16, Gelareh Taban via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I’d like to pitch some of the ideas that have been discussed in the

server working group around security.

To get more information on the server API group and its goals, see

https://swift.org/server-apis/. (TL;DR version is to come up with a set of
foundational APIs that work cross-platform, on all platforms supported by
Swift, including Linux.)

For security, we have divided the scope into SSL/TLS support and crypto

support. Our first goal and the subject of this pitch is TLS. This current
pitch is the result of various discussions that have taken place over the
past several months over the server working group mailing list and several
projects by groups such as Vapor, IBM, Zewo, etc.

Our plan is to start with the main ideas presented here and work on a

Swift library that we prototype and iterate on before finalizing on a
specific interface. Hopefully the ideas in this pitch are
non-controversial, aside from the naming of the method and protocols (which
is widely accepted as a `hard` problem).

# Problem

Since there is currently no standard Swift SSL/TLS library that is

compatible on both Apple and Linux, Swift projects use their TLS library of
choice (such as OpenSSL, LibreSSL, Security framework, etc). This results
in:

- fragmentation of the space as well as incompatibility of project

dependencies if more than one security package is needed by different
modules (a project cannot have both OpenSSL and LibreSSL in its dependency
graph)

- insecurity (using an unpatched or deprecated library such as OpenSSL on

macOS)

- unmaintainablity (using non-standard or non-native libraries)
- more complex code (using different APIs or code paths for each

platform).

So we want to propose a standard set of protocols that define the

behavior of the TLS service and how the application and the server and
networking layers beneath it interact with the TLS service. What
complicates this pitch is that the Swift in server space is new and none of
the interfaces have yet been defined, so this is really a work in
iteration.

# Design goals

We came up with the following design goals for a solution:

- Provide a consistent and unified Swift interface so that the developer

can write simple, cross-platform applications;

- Don't implement new crypto functionality and instead use existing

functions in underlying libraries;

- Plug-n-play architecture which allows the developer to decide on

underlying security library of choice, e.g., OpenSSL vs LibreSSL;

- Library should be agnostic of the transport mechanism (e.g., socket,

etc), whilst allowing for both blocking and non-blocking connections;

- Developers should be able to use the same TLS library for both client

and server applications.

# Proposal

The proposed solution basically defines a number of protocols for each

interface:

- Transport management
- TLS management

A basic diagram that shows the relationship between the proposed

protocols is shown below:

(See attached file: TLSServiceArchitecture.png)

![alt text](

https://raw.githubusercontent.com/gtaban/blogs/master/TLSServiceArchitecture.png
"Architecture of TLSService modules")

The transport management protocol essentially would be a combination of a

connection object (e.g., a socket pointer, a file descriptor, etc) and a
connection type.

This is the connection object that gets passed to the implementation of

the TLS service protocol, which also handles the read and write callbacks
to the connection object.

The TLS service protocol would define a sets of methods that deal with

TLS setup (certificates, server/client, etc), and TLS events (such as
receiving data, encrypting and writing to connection object or reading from
a connection object, decrypting and returning the data).

These methods are implemented by the TLS service which in turn uses its

choice of underlying security library. As an example, the TLS service uses
SecureTransport library on Apple platform and OpenSSL on Linux.

## How this would work

If an application requires TLS for its use case, it creates a TLS service

object and configures it based on its requirements.

The application then passes the TLS service object to its lower level

frameworks that deal with networking and communication. Each lower level
framework maintains an optional instance variable of type TLS service
protocol. If the optional variable exists, it is further passed down until
it gets to the lowest level that deals with the Swift transport layer APIs
(in the diagram above, this is the HTTP Management layer). When this layer
creates the connection using the transport layer APIs, it assigns the TLS
service object to the transport layer delegate. The Swift socket layer is
then responsible for calling the TLS service protocol methods that handle
the TLS functionality at the appropriate times.

# Source Compatibility:

As mentioned, the Swift in server space is still new and the interfaces

are currently under discussion. Although the proposed protocols are
designed to be as non-breaking as possible, they do place several
assumptions on the rest of the transport/application stack.

- The application layer must import and instantiate a TLS service object

which implements the TLS service protocol if it wants to enable TLS
service.

- Every framework layer above the transport management layer but below

the application layer (which includes HTTP and server frameworks) has an
optional object that implements the TLS service protocol. If the TLS object
exists, it is passed down to each layer below.

- The HTTP layer which sets up the transport management layer assigns the

TLS object to the transport management delegate if the object exists.

- The transport management layer which sets up the I/O communication

implements the transport management protocol.

- The transport management layer which sets up the I/O communication and

deals with the low level C system I/O, calls the appropriate TLS service
protocol methods whenever I/O data needs to be secured.

- The long term goal for the location of the TLS service protocol is

within the Foundation framework. In the short term, the protocol can live
within the transport management framework.

<TLSServiceArchitecture.png>_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Rien) #5

I subscribed to the list, thanks.

I guess security is something people “want to look into later”… and then somehow never get to it.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift

···

On 06 Apr 2017, at 23:04, Gelareh Taban <gtaban@us.ibm.com> wrote:

Hi Rien,

This is great, thanks for referencing your blogs/repo. I'll go through them.
(An unfortunate issue I have found with security is that, we need it, we expect it, but we don't want to worry about it :slight_smile:

The basic structure of what we are considering right now would to a large extent follow that of
https://github.com/IBM-Swift/BlueSSLService/
which invokes SecureTransport on Apple and OpenSSL on Linux.

For more details of some of the discussions, just follow this thread.
https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170320/000298.html

Would love to have your contributions here! :smiley:

gelareh

<graycol.gif>Rien ---04/06/2017 11:54:57 AM---Having just finished a client/server framework that builds on openSSL I sympathise with this proposa

From: Rien <Rien@Balancingrock.nl>
To: Gelareh Taban/Austin/IBM@IBMUS
Cc: swift-evolution@swift.org
Date: 04/06/2017 11:54 AM
Subject: Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library

Having just finished a client/server framework that builds on openSSL I sympathise with this proposal.

However, I wrote a few blogposts about my experiences with openSSL. And those leads me to believe that there is not much interest in secure networking. The number of hits on those posts are quite low (anaemic even) when compared to -for example- posts on socket programming.

While the sketch you made below does not sound too bad, I am afraid that the API will become complex so fast, that it will not be much easier to use than openSSL/LibreSSL etc. But don’t let that stop you :wink:

Regards,
Rien

PS: https://github.com/Balancingrock/SecureSockets

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift

> On 06 Apr 2017, at 18:16, Gelareh Taban via swift-evolution <swift-evolution@swift.org> wrote:
>
> Hi all,
>
> I’d like to pitch some of the ideas that have been discussed in the server working group around security.
>
> To get more information on the server API group and its goals, see https://swift.org/server-apis/. (TL;DR version is to come up with a set of foundational APIs that work cross-platform, on all platforms supported by Swift, including Linux.)
>
> For security, we have divided the scope into SSL/TLS support and crypto support. Our first goal and the subject of this pitch is TLS. This current pitch is the result of various discussions that have taken place over the past several months over the server working group mailing list and several projects by groups such as Vapor, IBM, Zewo, etc.
>
> Our plan is to start with the main ideas presented here and work on a Swift library that we prototype and iterate on before finalizing on a specific interface. Hopefully the ideas in this pitch are non-controversial, aside from the naming of the method and protocols (which is widely accepted as a `hard` problem).
>
> # Problem
>
> Since there is currently no standard Swift SSL/TLS library that is compatible on both Apple and Linux, Swift projects use their TLS library of choice (such as OpenSSL, LibreSSL, Security framework, etc). This results in:
> - fragmentation of the space as well as incompatibility of project dependencies if more than one security package is needed by different modules (a project cannot have both OpenSSL and LibreSSL in its dependency graph)
> - insecurity (using an unpatched or deprecated library such as OpenSSL on macOS)
> - unmaintainablity (using non-standard or non-native libraries)
> - more complex code (using different APIs or code paths for each platform).
>
> So we want to propose a standard set of protocols that define the behavior of the TLS service and how the application and the server and networking layers beneath it interact with the TLS service. What complicates this pitch is that the Swift in server space is new and none of the interfaces have yet been defined, so this is really a work in iteration.
>
> # Design goals
>
> We came up with the following design goals for a solution:
>
> - Provide a consistent and unified Swift interface so that the developer can write simple, cross-platform applications;
> - Don't implement new crypto functionality and instead use existing functions in underlying libraries;
> - Plug-n-play architecture which allows the developer to decide on underlying security library of choice, e.g., OpenSSL vs LibreSSL;
> - Library should be agnostic of the transport mechanism (e.g., socket, etc), whilst allowing for both blocking and non-blocking connections;
> - Developers should be able to use the same TLS library for both client and server applications.
>
>
> # Proposal
>
> The proposed solution basically defines a number of protocols for each interface:
> - Transport management
> - TLS management
>
> A basic diagram that shows the relationship between the proposed protocols is shown below:
>
> (See attached file: TLSServiceArchitecture.png)
>
> ![alt text](https://raw.githubusercontent.com/gtaban/blogs/master/TLSServiceArchitecture.png "Architecture of TLSService modules")
>
>
> The transport management protocol essentially would be a combination of a connection object (e.g., a socket pointer, a file descriptor, etc) and a connection type.
>
> This is the connection object that gets passed to the implementation of the TLS service protocol, which also handles the read and write callbacks to the connection object.
>
> The TLS service protocol would define a sets of methods that deal with TLS setup (certificates, server/client, etc), and TLS events (such as receiving data, encrypting and writing to connection object or reading from a connection object, decrypting and returning the data).
> These methods are implemented by the TLS service which in turn uses its choice of underlying security library. As an example, the TLS service uses SecureTransport library on Apple platform and OpenSSL on Linux.
>
> ## How this would work
>
> If an application requires TLS for its use case, it creates a TLS service object and configures it based on its requirements.
>
> The application then passes the TLS service object to its lower level frameworks that deal with networking and communication. Each lower level framework maintains an optional instance variable of type TLS service protocol. If the optional variable exists, it is further passed down until it gets to the lowest level that deals with the Swift transport layer APIs (in the diagram above, this is the HTTP Management layer). When this layer creates the connection using the transport layer APIs, it assigns the TLS service object to the transport layer delegate. The Swift socket layer is then responsible for calling the TLS service protocol methods that handle the TLS functionality at the appropriate times.
>
>
> # Source Compatibility:
>
> As mentioned, the Swift in server space is still new and the interfaces are currently under discussion. Although the proposed protocols are designed to be as non-breaking as possible, they do place several assumptions on the rest of the transport/application stack.
>
> - The application layer must import and instantiate a TLS service object which implements the TLS service protocol if it wants to enable TLS service.
> - Every framework layer above the transport management layer but below the application layer (which includes HTTP and server frameworks) has an optional object that implements the TLS service protocol. If the TLS object exists, it is passed down to each layer below.
> - The HTTP layer which sets up the transport management layer assigns the TLS object to the transport management delegate if the object exists.
> - The transport management layer which sets up the I/O communication implements the transport management protocol.
> - The transport management layer which sets up the I/O communication and deals with the low level C system I/O, calls the appropriate TLS service protocol methods whenever I/O data needs to be secured.
> - The long term goal for the location of the TLS service protocol is within the Foundation framework. In the short term, the protocol can live within the transport management framework.
>
> <TLSServiceArchitecture.png>_______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution