HTTPS protocols: TLS, SSL, SNI, ALPN, PNP, snialpn

HTTPS protocols: TLS, SSL, SNI, ALPN, PNP, snialpn

HTTPS is now widely used. It brings security while introducing more complicated concepts to the Web. This includes a series of network protocols that have never been seen before. Now, based on the principle of HTTPS, Harttle tries to interpret these protocols in the most popular way.

HTTPS Overview

HTTPS is an HTTP built on secure communication and uses transport layer encryption (TLS or SSL. The objective is to protect user privacy (such as preventing HTTP Content intercepted by network nodes) and data integrity (such as strong advertisement insertion by carriers). End-to-end encryption is used to prevent man-in-the-middle attacks.

TLS/SSL is a protocol under the application layer above the transport layer, so the content of the HTTP protocol is not affected. These encryption uses asymmetric encryption algorithms, so an official public key is required, which is the key infrastructure (CA ). Therefore, various browsers have built-in CA root certificates. These CAs can further authorize other domain names so that your browser can authenticate the domain names being accessed.

If you want your service to support HTTPS, you can register your domain name with CA. There are some free CAS such as GoDaddy, Let's Encrypt, CloudFlare and so on.

HTTPS interaction example

The following Wireshark log records a GET request sent to the https://github.com/harttle, you can see the main interaction process of several protocols:

• TCP. The first three rows complete a SYN/ACK (also known as the three-way handshake), and the TCP connection has been successfully established.
• TLS. Lines 4-5 begin the TLS handshake to create the encryption layer.
• TLS has many extension protocols, such as SNI, PNP, and ALPN (see the following figure), which occur in the ClientHello and ServerHello phases of TLS.

TLS/SSL

The predecessor of TLS is SSL. the TCP/IP protocol stack runs on top of TCP to exchange keys and form a Record Layer ). TLS is the core protocol of HTTPS. The main difference between HTTPS interaction and HTTP interaction lies in this layer:

Preparations for key exchange and server Certificate verification are required before ciphertext transmission. Therefore, TLS also has a handshake stage. The main steps are as follows: Send ClientHello from the client, send ServerHello from the server, and then send Certificate from the server, then send the KeyExchange message to each other, and finally send ChangeCipherSpec to notify the other party that the message is ciphertext later. For details about interaction and protocol fields, see RFC 5246 (TLSv1.2) and RFC 6176 (TLSv2.0 ).

TLS is widely used as the encryption protocol in the TCP/IP protocol stack. To support Protocol Extensions of common mechanisms, RFC 4366-TLS Extensions is defined. TLS has been used by email service, Web Service, FTP, etc. Here is a list of extended protocols.

This article focuses on Web Service (HTTPS)-related extensions, such as SNI, PNP, and ALPN. These protocols add new features to TLS by extending the ClientHello/ServerHello messages of TLS. For this reason, let's take a look at the structure of the ClientHello message (ServerHello is similar ):

 
 

  
  
struct { 
  
  
    ProtocolVersion client_version; 
  
  
    Random random; 
  
  
    SessionID session_id; 
  
  
    CipherSuite cipher_suites<2..2^16-2>; 
  
  
    CompressionMethod compression_methods<1..2^8-1>; 
  
  
    select (extensions_present) { 
  
  
        case false: 
  
  
            struct {}; 
  
  
        case true: 
  
  
            Extension extensions<0..2^16-1>; 
  
  
    }; 
  
  
} ClientHello; 
 
 

Note that the last field can have a maximum of 65536 extensions. The Extension is defined as a two-byte ExtensionType and the corresponding opaque data. The SNI, PNP, and ALPN values below are one of them.

SNI

SNI (Server Name Indication) specifies the host Name to be connected during TLS handshake. The SNI protocol is used to support multiple domain names for the same IP address (and port.

Because the server needs to send a Certificate (Certificate) to the client during the TLS handshake, you need to know the domain name requested by the customer (because the certificates for different domain names may be different ). At this time, some people have to ask, isn't the Host to be connected the Host name when the HTTP is initiated! This is a misunderstanding of the HTTPS mechanism. When TLS Handshake occurs, HTTP interaction has not started yet. Naturally, the HTTP header has not yet reached the server. The SNI protocol is defined in RFC 6066:

 
 

  
  
struct { 
  
  
    NameType name_type; 
  
  
    select (name_type) { 
  
  
        case host_name: HostName; 
  
  
    } name; 
  
  
} ServerName; 
  
  
 
  
  
enum { 
  
  
    host_name(0), (255) 
  
  
} NameType; 
  
  
 
  
  
opaque HostName<1..2^16-1>; 
  
  
struct { 
  
  
    ServerName server_name_list<1..2^16-1> 
  
  
} ServerNameList; 
 
 

Let's take a look at the example at the beginning of this article. The SNI Extension field in ClientHello sent from row 4th to github.com:

 
 

  
  
Extension Header     ||            Extension Payload (SNI) 
  
  
--------------------------------------------------------------------------------------------------- 
  
  
ExtensionType Length || PayloadLength Type      ServerLength ServerName 
  
  
--------------------------------------------------------------------------------------------------- 
  
  
00 00         00 0f  00 0d            00        00 0a        67 69 74 68 75 62 2e 63 6f 6d 
  
  
sni(0)        15     || 13            host_name 10           github.com 
 
 

ALPN/PNP

ALPN (Application-Layer Protocol Negotiation) is also an extension of the TLS Layer, used to negotiate the Protocol used by the Application Layer. It was originally used to support the Google SPDY protocol (now standardized as HTTP/2 ). Due to the TLS client and server version problems, SPDY-> HTTP/2 and PNP-> ALPN switching has caused a lot of pain points:

• The day Google Chrome disables HTTP/2
• Starting with HTTP/2, the website cannot be accessed.

Therefore, promoting Web infrastructure in a standard-first manner has become the consensus of today's Web platform. Here we will not mention the (class) browser vendors that are still engaged in workshop-style production, any implementations that block the development of Web platforms (or even standards, such as XHTML, OSI ...) It will be eliminated sooner or later.

To put it bluntly, ALPN is defined in RFC 7301-Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension,

 
 

  
  
enum { 
  
  
    application_layer_protocol_negotiation(16), (65535) 
  
  
} ExtensionType; 
  
  
 
  
  
opaque ProtocolName<1..2^8-1>; 
  
  
 
  
  
struct { 
  
  
    ProtocolName protocol_name_list<2..2^16-1> 
  
  
} ProtocolNameList; 
 
 

Let's take a look at the example at the beginning of this article. The ALPN Extension field in ClientHello sent from row 4th to github.com:

 
 

  
  
Extension Header     ||            Extention Payload (ALPN) 
  
  
--------------------------------------------------------------------------------------------------- 
  
  
ExtensionType Length || PayloadLength StringLength Protocol StringLength Protocol 
  
  
--------------------------------------------------------------------------------------------------- 
  
  
00 10         00 0e  00 0c            02           68 32    08           68 74 74 70 2f 31 2e 31 
  
  
alpn(16)      14     || 12            2            h2       8            http/1.1 
 
 

The message body of Extention contains multiple strings (protocol_name_list), indicating all application-layer protocols supported by the client. The preceding example contains h2 and http/1.1. The SPDY/2 is added to clients that support spdy. You need to select one of the ServerHello fields given by the server. In this example, the ALPN field of ServerHello is:

 
 

  
  
00 10 00 0b 00 09 08 68 74 74 70 2f 31 2e 31 
  
  
                     h  t  t  p  /  1  .  1 
 
 

In this way, the Server and Client reach a consensus using the ALPN protocol and will use HTTP/1.1 protocol for communication after the handshake ends.

Reference and thanks

This section describes a typical HTTPS interaction process from the key layer of TLS. The principles and main contents of TLS, SNI, ALPN, and other protocols are introduced in turn based on the byte sequence given by packet capture.