ネットスケープコミュニケーションズ社がSSLの最初のバージョンとして設計していたが、設計レビューの段階でプロトコル自体に大きな脆弱性が発見され、破棄された。このため、SSL 1.0を実装した製品はない。
ネットスケープコミュニケーションズ社はSSL 1.0の問題を修正して再設計し、1994年にSSL 2.0として発表した。また、同社のウェブブラウザであるNetscape Navigator 1.1においてSSL 2.0を実装した。
その後、SSL 2.0にもいくつかの脆弱性が発見され、SSL 3.0において修正された。SSL 2.0の脆弱性のひとつは、ネゴシエーションの情報を改竄すると、提示する選択肢のうち最弱のアルゴリズムを使わせることができ（ダウングレード攻撃）、改竄を受けたことを検出できないというものである。さらに悪いことに、この脆弱性を利用すると、双方がSSL 3.0をサポートしていてもSSL 2.0で接続させることさえ可能になる。
SSL 3.0ではSSL 2.0との互換性を提供するにあたり、乱数領域を使った細工を加えることで、このような攻撃を検出する仕組みを組み込んだ。しかし一部の製品においてこの細工の実装に問題があったため、結局のところ無視されていることが多い[1]。SSL 3.0以降に対応した実装が十分に普及したものとして、Internet Explorer 7やMozilla Firefox 2、Opera 9などは、初期状態でSSL 2.0を無効にしている[2][3][4]。この決定を受け、SSL 2.0しか対応していなかったサーバでも、SSL 3.0以降へ対応する動きが広まっている[5]。
SSL2.0にはチェーン証明書がない。 したがって、ルートCAから発行したSSLサーバ証明書しか使うことができない。
ネットスケープコミュニケーションズ社はSSL 2.0の問題を修正するとともに機能追加を行い、1995年にSSL 3.0を発表した。また、Netscape Navigator 2.0においてSSL 3.0を実装した。
IETFのTLSワーキンググループは ⇒RFC 2246としてTLS1.0を公表した。TLS 1.0の標準化作業は1996年に開始され、年内に完了する予定だったが、いくつかの問題に阻まれ、公表は1999年まで遅延した。
TLS 1.0が提供する機能はSSL 3.0とあまり変わらないが、アルゴリズムやルートCAの自己署名証明書の取扱いなどの仕様の詳細が変更されたことに加え、これまであまり実装されていなかった選択肢のいくつかが必須と定められた。このため、TLS 1.0を実装した製品が普及するまでには、さらに数年を要した。
なおTLS 1.0はSSL 3.0より新しい規格であることを示すため、ネゴシエーションにおけるバージョン番号は3.1となっている。
2006年に ⇒RFC 4346としてTLS 1.1が制定された。TLS 1.0からの変更点は、新しく発見された攻撃手法に対する耐性の強化が中心である。また、AES暗号が選択肢に加わった。
ネゴシエーションにおけるバージョン番号は3.2となっている。
2008年8月に ⇒RFC 5246としてTLS 1.2が制定された。CBC攻撃の耐性を上げるため、初期化ベクトルを明示的に指定することにし、さらにパディングの処理が改善された。また、予期せぬ回線クローズ後に、セッションを再開できるようになった。ハッシュのアルゴリズムにSHA256が追加された。ネゴシエーションにおけるバージョン番号は3.3となっている。
SSLは暗号化、認証、改竄検出の機能を提供する。具体的なアルゴリズムはそれぞれ複数の選択肢が定義されており、SSL通信の開始時に行われるネゴシエーション時に、双方が許容するアルゴリズムの中からそれぞれ一つが選択される。
選択肢によっては、攻撃への耐性の強度が大きく変化する場合もある（極端な例だが、双方が同意すれば「暗号化なし」を選択することもできる）。許容できない選択肢はあらかじめネゴシエーションの候補から外しておいたり、また望ましくないアルゴリズムが選択された場合はユーザーに警告したりといった対策が考えられる。一般に公開されている製品は、実際にこれらの対策が取られている。
なお、選択できるアルゴリズムはSSLのバージョンによって異なる。また、暗号化、認証、改竄検出の3つをひとまとめにして選択肢が定義されており、しかも全ての組み合わせが網羅されているわけではないので、同時に利用できない組み合わせも存在する。
共通鍵暗号に基づく暗号化を提供する。以下のアルゴリズムが選択肢として定義されている。
SSLの各バージョンで使用できる暗号化アルゴリズム （× = 未対応、○ = 選択可能、◎ = 実装必須）アルゴリズムSSL 2.0SSL 3.0TLS 1.0TLS 1.1
暗号化なし×○○○
RC2○○○○
RC4○○○○
IDEA○○○○
DES○○○○
トリプルDES○○◎◎
AES×××○
共通鍵は、クライアントとサーバの双方から提供される乱数に基づいて決定される。双方で生成した乱数を組み合わせて使用するため、リプレイ攻撃では同一の共通鍵を得ることはできない。
鍵の盗聴を防ぐ仕組みとして、サーバ証明書がRSA暗号を用いて署名されている場合は、クライアントから送る鍵情報の一部をサーバの公開鍵で暗号化することができる。サーバの秘密鍵を知らない部外者は、この情報を復号できない。あるいは（RSA暗号を使っていない場合などは）Diffie-Hellman鍵共有アルゴリズムを使うこともできる。
SSLは公開鍵証明書に基づく認証を提供する。認証に使用する署名アルゴリズムの選択肢は以下のとおりである。
SSLの各バージョンで使用できる署名アルゴリズム （× = 未対応、○ = 選択可能、◎ = 実装必須）アルゴリズムSSL 2.0SSL 3.0TLS 1.0TLS 1.1
RSA○○○◎
DSA×○◎○
SSLでは通常、サーバだけが証明書を提示し、クライアントがその正当性を確認する。クライアント認証はオプションとなっており、必要な場合にはサーバがクライアントに対して証明書の提示を求める。
なりすましを防ぐために、証明書には認証局 (CA; Certification Authority) による電子署名が必要となる。またサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。この確認を行わない場合、攻撃者はサーバAの管理者でなくても、自分が管理するサーバBの正当な証明書を取得して、その証明書を使ってサーバAを名乗ることができてしまう。
証明書に関する問題は、#証明書の正当性の節を参照せよ。
なお証明書には有効期限が設定されている。暗号理論およびコンピュータの計算能力は日々進歩しており、現在安全とみなされる技術であっても長年にわたって安全性を保てる保証はない。また暗号技術の制約上、莫大な計算能力をつぎ込んで解読を続ければ、いつか暗号は解読されると考えるべきである。このため、一定期間ごとに証明書を再発行し、鍵を変更するとともに必要に応じて使用するアルゴリズムも更新している。