Transport Layer Security (TLS), anciennement nommé Secure Socket Layer (SSL), est un protocole de sécurisation des échanges sur Internet, développé à l'origine par Netscape (SSL version 2 et SSL version 3). Il a été renommé en Transport Layer Security (TLS) par l'IETF suite au rachat du brevet de Netscape par l'IETF en 2001.

Le groupe de travail correspondant à l'IETF a permis la création des RFC 2246 pour le TLS et RFC 4347 pour son équivalent en mode datagramme, le DTLS. Depuis son rapatriement par l'IETF, le protocole TLS a vécu deux révisions subséquentes : TLSv1.1 décrite dans la RFC 4346 et publiée en 2006 et TLSv1.2, décrite par la RFC 5246 et publiée en 2008.

Il y a très peu de différences entre SSL version 3 et TLS version 1 (qui correspond à la version 3.1 du protocole SSL) rendant les deux protocoles non interopérables, mais TLS a mis en place un mécanisme de compatibilité ascendante avec SSL. En outre, TLS diffère de SSL pour la génération des clés symétriques. Cette génération est plus sécurisée dans TLS que dans SSLv3 dans la mesure où aucune étape de l'algorithme ne repose uniquement sur MD5 pour lequel sont apparues quelques faiblesses en cryptanalyse.

Par abus de langage, on parle de SSL pour désigner indifféremment SSL ou TLS.

TLS fonctionne suivant un mode client-serveur. Il fournit les objectifs de sécurité suivants:

Avec le développement d'Internet, de nombreuses sociétés commerciales proposent des achats en ligne pour les particuliers. L'offre croît tous les jours, mais le chiffre d'affaires dégagé par le commerce électronique reste encore modeste, car le client n'a pas encore une confiance totale dans le paiement par carte bancaire. Une des façons de sécuriser ce paiement est d'utiliser des protocoles d'authentification et de chiffrement tels que TLS. Il est néanmoins strictement interdit que ces sociétés puissent stocker sur leurs propres serveurs des données bancaires appartenant aux clients. C'est pour cela que pour chaque nouvelle commande, le client est obligé de redonner le code de la carte de paiement.

Avec un système SSL/TLS, tous les risques sont écartés, et le client ne risque absolument rien. Il serait d'ailleurs paradoxal de n'avoir pas confiance en cette technologie, et de préférer réaliser un paiement par chèque ou par mandat, qui est, d'après différentes études, environ 20 fois plus risqué que d'utiliser la toute première version de SSL. De plus il est à noter que les distributeurs bancaires courants utilisent presque tous cette même technologie pour faire transiter les informations vers la banque, et utilisent parfois même une version plus ancienne de SSL que les sites de e-commerce actuels, et sont donc pour certains vraisemblablement moins sécurisés (mais tout de même inviolables) qu'un achat sur Internet. Voila de quoi rassurer les anxieux.

La session chiffrée est utilisée généralement lors de l'envoi du numéro de carte bancaire, mais elle peut l'être dans d'autres cas. Le chiffrement est réalisé par à la fois un chiffrement asymétrique (qui va permettre une authentification), comme par exemple l'algorithme RSA, et à la fois par un chiffrement symétrique (qui est plus léger à réaliser qu'un chiffrement asymétrique) et qui va assurer la transmission des informations (comme par exemple le AES). On y adjoint une fonction de hachage, comme le SHA-1, pour s'assurer que les données sont transmises sans être corrompues.

En 2008, TLS est utilisé par la plupart des navigateurs Web. On reconnaît qu'une transaction est sécurisée lorsqu'une clé ou un cadenas fermé s'affiche dans un coin inférieur de l'écran ainsi qu'à gauche dans la barre d'adresse1, l'adresse commence par https://...

Dans la pile de protocole TCP/IP, SSL se situe entre la couche application (comme HTTP, FTP, SMTP, etc.) et la couche transport TCP.

Son utilisation la plus commune reste cependant en dessous de HTTP. La couche SSL est implémentée par la couche session de la pile, ce qui a deux conséquences :