SSL/TLS: Difference between revisions
| Line 14: | Line 14: | ||
Transport Layer Security (TLS) is the successor of Secure Sockets Layer (SSL). They are both cryptographic protocols designed to provide communications security over a computer network. | Transport Layer Security (TLS) is the successor of Secure Sockets Layer (SSL). They are both cryptographic protocols designed to provide communications security over a computer network. | ||
They use [[Public_Key_Security#Asymmetric_Cryptography|asymmetric cryptography]], [[Public_Key_Security#Public_Key_Infrastructure_.28PKI.29| | They use [[Public_Key_Security#Asymmetric_Cryptography|asymmetric cryptography]], [[Public_Key_Security#Public_Key_Infrastructure_.28PKI.29|public key infrastructure (PKI)]] and [[Public_Key_Security#X.509|X.509]] certificates to ''authenticate'' the counterparty with whom they are communicating and to ''negotiate a symmetric session key''. This session key is then used to encrypt data flowing between the parties. This allows for data confidentiality and message authentication. An important property in this context is forward secrecy, so the short-term session key cannot be derived from the long-term asymmetric secret key. | ||
For more details about PKI, keys and certificates see [[Public Key Security#Overview|Public Key Security]]. | For more details about PKI, keys and certificates see [[Public Key Security#Overview|Public Key Security]]. | ||
When the client requests a secure connection to exchange the session key, a handshake takes place: the server passes its public key in the form of a [[Public_Key_Security#Certificate|certificate]]. The certificate contains the identity of the server (URL), its public key and a digital signature that validates the certificate. The client verifies the digital signature and decides whether the certificate is trusted or not. If the certificate is trusted, the client generates the session key (two-way encryption key) using its private key, and further communication between the two parties is encrypted using the two-way encryption key. | When the client requests a secure connection to exchange the session key, a handshake takes place: the server passes its public key in the form of a [[Public_Key_Security#Certificate|certificate]]. The certificate contains the identity of the server (URL), its public key and a digital signature that validates the certificate. The client verifies the digital signature and decides whether the certificate is trusted or not. If the certificate is trusted, the client generates the session key (two-way encryption key) using its private key, and further communication between the two parties is encrypted using the two-way encryption key. | ||
Revision as of 23:19, 7 April 2018
External
- Good SSL introductory article on Apache httpd web site http://httpd.apache.org/docs/2.4/ssl/ssl_intro.html
- Mozilla Introduction to SSL https://developer.mozilla.org/en-US/docs/Archive/Security/Introduction_to_SSL
- https://en.wikipedia.org/wiki/Transport_Layer_Security
Internal
Overview
Transport Layer Security (TLS) is the successor of Secure Sockets Layer (SSL). They are both cryptographic protocols designed to provide communications security over a computer network.
They use asymmetric cryptography, public key infrastructure (PKI) and X.509 certificates to authenticate the counterparty with whom they are communicating and to negotiate a symmetric session key. This session key is then used to encrypt data flowing between the parties. This allows for data confidentiality and message authentication. An important property in this context is forward secrecy, so the short-term session key cannot be derived from the long-term asymmetric secret key.
For more details about PKI, keys and certificates see Public Key Security.
When the client requests a secure connection to exchange the session key, a handshake takes place: the server passes its public key in the form of a certificate. The certificate contains the identity of the server (URL), its public key and a digital signature that validates the certificate. The client verifies the digital signature and decides whether the certificate is trusted or not. If the certificate is trusted, the client generates the session key (two-way encryption key) using its private key, and further communication between the two parties is encrypted using the two-way encryption key.