Bug 130 - TLS: SNI support for server connections
Summary: TLS: SNI support for server connections
Status: NEW
Alias: None
Product: resiprocate
Classification: Unclassified
Component: stack (libresip) (show other bugs)
Version: unspecified
Hardware: All All
: P1 enhancement
Assignee: Owner of all unassigned bugs
Depends on:
Blocks: 101 131
  Show dependency treegraph
Reported: 2016-08-05 08:50 CDT by Daniel Pocock
Modified: 2016-08-06 02:45 CDT (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Pocock 2016-08-05 08:50:55 CDT
Detect if incoming connections request a specific hostname/domain using SNI and reply with the appropriate server certificate.
Comment 1 Daniel Pocock 2016-08-05 08:56:02 CDT
To support Automated Certificate Management Environment (ACME) for Let's Encrypt and potentially other CAs, it would be desirable to support Domain Validation with Server Name Indication (DVSNI) as part of the server-side SNI implementation.

Comment 2 Daniel Pocock 2016-08-05 09:05:14 CDT
This has been raised on the mailing list:

Comment 3 Daniel Pocock 2016-08-05 09:14:37 CDT
How should SNI server support work:

- transports can continue to be configured the way they are now and work the same way

- if a connection comes in without SNI, the default certificate configured for the transport should be used, as it is now

- configuration support at the stack level and in repro.config for adding supplementary certificates / virtual hosted domains

- if a connection request comes in with SNI and the certificate is available, it should be used instead of the default certificate for the transport

- some parameters for the transport (e.g. client verification mode) remain constant

- other per-transport parameters (RecordRouteUri) may need to be adjusted based on the domain selected by SNI

- this flexibility could be achieved by creating additional "virtual" transports in repro.config, possibly overlapping the bind addresses of existing transports, or maybe creating a wildcard/regex rule or lookup table for Record Route URI values
Comment 4 Daniel Pocock 2016-08-06 02:45:49 CDT
Transport<n>Type is another parameter that may need to vary based on SNI.  e.g. some domains may be for SIP over TLS, while other domains may be for WebSockets over TLS (WSS)

It may be worthwhile looking at whether a single transport can serve either SIP or WebSockets dynamically even on the same domain.