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を名乗ることができてしまう。
証明書に関する問題は、#証明書の正当性の節を参照せよ。
なお証明書には有効期限が設定されている。暗号理論およびコンピュータの計算能力は日々進歩しており、現在安全とみなされる技術であっても長年にわたって安全性を保てる保証はない。また暗号技術の制約上、莫大な計算能力をつぎ込んで解読を続ければ、いつか暗号は解読されると考えるべきである。このため、一定期間ごとに証明書を再発行し、鍵を変更するとともに必要に応じて使用するアルゴリズムも更新している。
SSLの各レコードには、データのハッシュ値が付加されている。改竄されたデータはハッシュ値と一致しなくなるため、受信者は改竄を検出できる。各レコードにはシーケンス番号が振られており、このシーケンス番号も含めてハッシュ値が算出されているため、一部のレコードを重複して送りつける形のリプレイ攻撃も検出できる。また、（アプリケーション層プロトコルによる代替手段がない限り）通信の終了を知らせるレコードを送り合うことになっており、これが送られないうちに接続が切断された場合は、強制切断攻撃による介入を受けたと判断することができる。
ハッシュ関数の選択肢は以下のとおりである。
SSLの各バージョンで使用できるハッシュ関数 （× = 未対応、○ = 選択可能、◎ = 実装必須）アルゴリズムSSL 2.0SSL 3.0TLS 1.0TLS 1.1
MD5○○○○
SHA-1×○◎◎
SSLは特定のアプリケーション層プロトコルに依存しないため、HTTP以外にも多くのプロトコルにおいて採用され、クレジットカード情報や個人情報、その他の機密情報を通信する際の手段として活用されている。
既存のアプリケーション層プロトコルでSSLを利用する場合、大きく2つの適用方式が考えられる。まずひとつは、下位層（通常はTCP）の接続を確立したらすぐにSSLのネゴシエーションを開始し、SSL接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。もうひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でSSLへの切り替えを指示する方式である。
前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、既存のポート番号とは別にSSL対応用のポート番号が必要となる。実態としては、SSLの最初の適用例であるHTTPSをはじめとして、前者の方式を使うことが多い。
前者の方式のもうひとつの問題点として、名前ベースのバーチャルホストを提供できないという点がある。なぜなら、証明書の検証はSSLネゴシエーションの一部として実施されるが、この時点ではアプリケーション層の通信が開始されていないためサーバはホスト名を知らず、証明書を使い分けることができないためである。
例外として、発行先ホスト名にワイルドカードを含めた1種類の証明書で対応できる場合は、証明書を使い分ける必要がないので、名前ベースのバーチャルホストを提供できる。またIPアドレスベースのバーチャルホストであれば、SSLネゴシエーションの時点でIPアドレスは既知なので、問題はない。
SSLを導入さえすればセキュリティーが確保できるという認識は誤っている。SSL通信は、平文での通信に比べて余分な計算機能力を使用するため、本当に必要なとき以外は使用しないことが多い。システムはデータの重要性を判断することができないので、SSLが必要なときに正しく使われているかどうかは、利用者自身が判断しなければならない。Mozilla Firefoxにおける南京錠アイコンの例
特にWorld Wide Webでは、ハイパーリンクによるページ遷移を繰り返して処理を行うため、どの通信でSSLが使用されているか把握することが重要になる。多くのウェブブラウザは、画面のどこかに南京錠の絵を表示したり、アドレスバーの色を変化させたりして、利用者に情報を提供している。
また実際に使用するアルゴリズムは双方のネゴシエーションによって決まるため、SSLを使用していても、システムとして許容はするが推奨できないアルゴリズムが採用される可能性がある。このような場合もダイアログメッセージなどを使って利用者に警告すべきである。
SSLは公開鍵証明書を用いて認証を行い、なりすましを極力排除しようとする。しかしシステムの自動的な対応には限界があり、すべてのなりすましを検出できるわけではない。
電子証明書には認証局による電子署名が与えられる。
