This figure illustrates subjects entering a trial and ending at different times. S, M, and L indicate a short, medium, and long serial times. The solid circle represents an event occurrence and the open circles represent censoring.
This is a survival guide to the eye-glazing topic of TLS/SSL and X.509 (SSL) certificates - including self-signed certificates. These are elements in what is loosely called a Public Key Infrastructure (PKI).
On Ubiquitous SSL and ACME: It has become a de-facto standard today to use TLS (rather, the presence of a certicate used in TLS) to authenticate web sites (let us not speak unkindly of DNSSEC - an infinitely better solution - but, rather, mourn its determined efforts at seppuku). Indeed, the dominant search engines now use the absence of HTTPS (HTTP over TLS) to penalise search results (meaning that you get policy based results not just content based results). However, this policy has a number of collateral effects, namely: You need to have (buy) an SSL certificate; 'the law of big numbers' states that even a tiny proportion of misconfigurations will generate enough security alerts (red status lines etc.) that the whole enterprise will collapse under its own weight. Enter stage left, Let's Encrypt and Automatic Certificate Management Environment (ACME). Let's Encrypt provide free 90 day certificates and automate the initial install and subsequent certificate rollovers for a number of popular platforms using ACME as a base but with a manual overide if all else fails. The first standard based on their work is RFC 8555 which documents the process of automating the verification of domain ownership and cerificate issue (and revokation).
Note: The main repository for RFCs is maintained by the IETF, text versions (the normative reference, but PDF and HTML versions are also available) may be viewed at www.ietf.org/rfc/rfcXXXX.txt or www.rfc-editor.org/rfc/rfcXXXX.txt (where XXXX is the 4 digit RFC number - left padded with zeros as necessary). Currently published RFCs are pointed to -editor.org/info/rfcXXXX which contains various information and links to the text (normative) reference and PDF and HTML (non-normative) version. The RFC may also be viewed at which also contains various RFC status information including errata together with a list of alternative formats, such as, text, PDF and HTML (this is the working area version of the document). Finally, there is now a searchable RFC list.
The major use of SSL (X.509) certificates is in conjunction with the TLS/SSL protocol. Secure Sockets Layer (SSL) is a Netscape protocol originally created in 1992 to exchange information securely between a web server and a browser where the underlying network was insecure. It went through various iterations and is now at version 3 (dating from 1995) and used in a variety of clientserver applications. Since the demise of Netscape the SSL specifications will not be updated further. It is thus a dead standard, (dead as in a dead parrot) and indeed RFC 7568 has finally deprecated SSL v3. It is now officially a dead parrot and must not be used henceforth by order of the great and good (and, in this case, the eminently sensible). The IETF standardized Transport Layer Security (TLS) Version 1, a minor variation of SSL, in RFC 2246, Version 1.1 in RFC 4346, Version 1.2 in RFC 5246 and version 1.3 (representing a substantial change to the handshake protocol) in RFC 8446. In addition, a number of extensions are defined in RFC 3546 when TLS is used in bandwidth constrained systems such as wireless networks, RFC6066 defines a number of TLS extensions carried in an extended client hello format (introduced with TLS 1.2), RFC6961 defines a method for reducing traffic when a client requests the server to supply certificate status information. And RFC 7935 now defines what happens to TLS (and DTLS) when used in the IoT (Internet of Things or Thingies as we, in our iconoclastic way, prefer).
TLS/SSL does not have a well-known port number - instead when used with a higher layer protocol, such as HTTP, that protocol designates a secure variant, HTTPS in the case of HTTP, which does have a well-known (or default) port number. The designation HTTPS simply indicates that normal HTTP is being run on top of an TLS/SSL connection, which runs over TCP. In the case of HTTPS the well-known port number is 443, in the case of IMAPS - port 993, POP3S - port 995 etc..
The next level of description requires some familiarity with the terms MAC (Message Authentication Code), Secure hashes, symmetric and asymmetric cryptographic algorithms (and, post TLS 1.2, Empheral Diffie-Hellman Exchange). For those not comfortable with these terms they are covered in this Encryption survival guide. You may want to lie down for a while in a darkened room after reading that page.
The world turns again - slowly. RFC 8446, after a delay of some years, introduces TLS 1.3. TLS 1.3 contains substantial changes to the TLS handshake protocol including a new method of negotiating established sessions, increases the number of encrypted messages and decreases the number of messsages used in the handshake. TLS 1.3 breaks backward compatibility with TLS 1.2 under certain conditions. Thus, if either the server or client support TLS 1.3 then a TLS 1.2 (or TLS 1.1 peer) peer may not be able to negotiate a session connection without an upgrade.
In general TLS 1.3 reduces the number of round trips (RTTs) required to establish a connection, encrypts as much traffic as possible and has significantly reduced the number of options to tighten up basic security. The key item to note in the full handshake is that the first two messages (ClientHello(1)/ServerHello(2)) establish only the version being used and the crypto context. Having established a connection using the full handshake, subsequent sessions between the same client and server can be restarted (resumed in the jargon).
key_share: One (or more) structures identifying the supported_group and the shared (or public) value for the identified group. The client thus reduces the number of messages reqired for agreement by offering one (or more) key shares (which the peer uses to compute the operational session keys). If the client does not send a key share for a supported_groups that will be subsequently be chosen by the server then the server will send a HelloRetryRequest message which, in essence, tells the client to try again (ClientHello) with the required group for which is required a key_share identified in the key_share extension of the HelloRetryRequest message.
Once a session has been established using the TLS 1.3 Full Handshake it may be subsequently restarted (or resumed in the jargon) using the method shown on figure 2B, if, and only if, the server has sent one or more optional NewSessionTicket (Figure 2A, item 8A) messages. The RFC does not offer any guidance as to when resumption versus full handshake should be used. While certain messages can be omitted (notably Certificate and CertificateVerify) the number of round trips remains the same and the number of mandatory extensions in the ClientHello (1) increases. However, the fact that the Server may commence sending Record data (5) immediately following its Finished (4) message may offer an advantage in certain circumstances - notably, perhaps, after a communications failure where the server retains state information. Note: An additional procedure is available (termed 0-RTT in the RFC) which provides faster restarting (resumption) but at the expense of not being forward secure (if any key is compromised all communication started using 0-RTT procedures can be decrypted) and is not discussed further on this page.
Extensions, defined in RFC 3546 and primarily used in wireless networks, may be invoked in a backward compatible manner at ClientHello. RFC6066 significantly increases the number of TLS extensions including many which may be used on conventional (non-wireless) networks. The server is free to silently ignore any extensions it does not understand.
ServerHello (2): The ServerHello returns the selected protocol variant/version number, cipher suite and compression algorithm. The server sends a 32 octet random value (a nonce) which is used later to compute the symmetric keys. If the session ID in the ClientHello was 0 the server will create and return a session ID. If the ClientHello offered a previous session ID known to the server then a reduced Handshake is negotiated. If the client offered a session ID that was not recognized by the server, the server returns a new session ID and a full Handshake results.
ClientKeyExchange (5): The client computes what is called a pre-master key using the server and client random numbers (or nonces). It encrypts this key using the public key of the server obtained from the supplied X.509 certificate. Only the server can decrypt this message using its private key. Both sides independently compute a master key from the pre-master key using an algorithm defined in the standard. Any required session key is derived from this master key.
It has been shown that TLS (and DTLS) can be vulnerable to Man-in-The-Middle (MTM) attacks. To eliminate this possibility RFC 7627 redefines the method of computing the master secret (originally defined in RFC 5246) by replacing the server and client random numbers with a hash of the complete session from ClientHello to ClientKeyExchange. The client indicates it can use the new (redefined) master secret algorithm by sending, in its ClientHello, an empty extended_master_secret extension. If the server can support the new algorithm it will also mirror the empty extended_master_secret extension in its ServerHello. If either the client or server cannot support the new (RFC 7627) algorithm then clearly either may abort the session or continue with the legacy (RFC 5246) algorithm. 2b1af7f3a8