基礎

認証

ユーザーが本人であることを確認します。

認可

ユーザーにリソースにアクセスする権限を与えます。

認証と認可

家族が休暇で留守の間、ペットの世話をするために鍵のかかったドアまで歩いて行く人を想像してください。その人に必要なのは、次のことです。

認証

鍵の形で行われます。システムが正しい資格情報を持つユーザーにのみアクセスを許可するのと同じように、ドアのロックは正しい鍵を持つユーザーのみにアクセスを許可します。

認可

中に入ると、その人はキッチンにアクセスし、ペットフードが入っている戸棚を開ける許可を得ます。ただし、寝室に行ってちょっと昼寝する許可は与えられないかもしれません。

この例では、認証と承認が連携して機能します。ペットシッターには家に入る権利があり (認証)、家に入ると特定のエリアにアクセスできます (承認)。

	認証	承認
それは何をするのですか?	資格情報を確認する	権限を付与または拒否する
どのように機能しますか?	パスワード、生体認証、ワンタイムピン、アプリを通じて	セキュリティチームが管理する設定を通じて
それはユーザーに表示されますか?	はい	いいえ
ユーザーによって変更可能ですか?	部分的に	いいえ
データはどのように移動するのでしょうか?	ID トークンを通じて	アクセストークンを通じて

署名

ある物事について本人が同意した意思表示を表すもの。

デジタル署名は以下のことを証明するための技術。

ファイルの改ざんがされていないことを証明
ファイルの作成者が作成名義人によって作成されたことを証明

ハッシュ

クレデンシャル（Credential）

ネットワークセキュリティにおいて、ユーザーの認証に用いられる情報の総称。「資格情報」や「認証情報」とも呼ばれる。サービスが悪意ある不正なサービスではないことが判断できるようにするための鍵。

例：ID やパスワードなど

リクエストを行っているクライアントを識別。
リクエストでクライアントが代理となる第３者のサービスを識別。

SSO(single sign on)

1 度のユーザー認証で複数のシステムやサービスにアクセスできる認証スキーム。

メリット

ユーザーの利便性向上
- 1 度のログインで複数のシステムを利用できるため、追加の認証やログインの必要がなく、業務効率が向上します。
セキュリティの向上
- パスワードの使いまわしを防ぐことができ、パスワードを標的とするセキュリティイベントのリスクが軽減されます。
IT 管理者の運用業務の効率化
- ログイン情報が多ければそれだけ紛失・漏洩リスクも高まりますが、SSO では 1 セットの ID とパスワードの管理を強化すればよいので、運用業務の効率化が図れます。

認証方式

主に２つの認証方式があります。

リバースプロキシ方式

Web 上で認証を行う仕組みです。リバースプロキシと呼ばれる中継サーバーで認証を行い、リバースプロキシ経由で対象システムにアクセスします。既存システムに影響を与えることなく事前検証ができるため、手軽に導入ができます。

SAML（サムル）認証方式

SAML 認証を用いたログインの際、ユーザー認証に加えて、ログインする人の属性情報も同時に認証できるため、ユーザーのアクセス範囲を制限できます。これにより、特定の部署に所属する人しか、アクセスさせない、使える機能を制限する、といったアクセス制御が可能になり、セキュリティ対策が強化できるメリットもあります。

OAuth

ユーザーを承認するための技術。

OAuth は、ユーザー名とパスワードなどの実際の資格情報を共有せずに、あるサービスから別のサービスへ権限を与えるためのプロトコルです。これにより、ユーザーは 1 つのプラットフォームでサインインし、別のプラットフォームでアクションを実行したり、データを閲覧したりする権限を得られます。

OAuth は、アプリケーションの種類を問わず、権限の委譲を可能にします。特に、シングルサインオン（SSO）サービスからクラウドアプリケーションへの権限付与によく使われますが、任意の 2 つのアプリケーション間でも利用できます。他のプロトコルでも同様の機能を実現できますが、OAuth は最も広く採用されているプロトコルの 1 つです。

OAuth の仕組みは、家主が不在時に訪問者に家の鍵を直接渡す代わりに、鍵の入った金庫を開けるための一時的なコードを送る状況に例えられます。OAuth では、アプリケーション間でユーザー資格情報ではなく、承認トークンを送信してアクセスを許可します。

複数のアプリケーションを連携させるための便利な仕組み。

OAuth は、複数の Web サービスを連携して動作させるための仕組みです。通常の Web サービス利用では、個別にユーザー ID とパスワードを入力して認証する必要がありますが、OAuth を使えば、それらを入力せずにアプリケーション間の連携が可能になります。

OAuth は、ユーザーが自身のアカウントパスワードを共有せずに、サードパーティアプリケーションにデータへのアクセスを許可するプロトコルです。これにより、ユーザーはサードパーティアプリに対して、自分のデータ、アカウント情報、写真、文書など、特定のサーバーに保存されているリソースへのアクセスを認証・承認できます。また、ワンクリックログインなど、ログイン情報を毎回入力せずに Web サービスに自身を識別させる機能にも OAuth が使用されています。

フロー

1. クレデンシャルの取得：OAuth を利用するサードパーティサービスは、まずクレデンシャルを取得する必要があります。クレデンシャルには 2 種類あり、1 つはリクエスト元のクライアントを識別するため、もう 1 つはクライアントが代理となる第三者サービスを識別するために使用されます。簡単に言えば、クレデンシャルはそのサービスが正当であることを証明する鍵です。
1. ユーザー情報使用の許可要求：取得したクレデンシャルを使用して、サードパーティのユーザー情報使用許可を求めます。クレデンシャルによりリクエストに「署名」を付け、ユーザーがソーシャルログインを要求した際に、サードパーティサービスへの「正当な」リダイレクトを行い、ユーザー情報の使用許可を求めます。この署名には通常 30 分程度の短い有効期限があり、再利用を防ぐことでセキュリティを高めています。ユーザーが情報使用に同意すると、そのアカウントの権限を持つアクセストークンが取得できます。
1. ユーザー情報の取得：アクセストークンを使用して、サードパーティサービスからユーザー情報を直接取得します。OAuth をユーザー認証に使用する場合、ユーザー情報を取得してセッションを生成した時点でアクセストークンは破棄されます。通常、取得される情報はアカウント ID、ニックネーム、サムネイル URL などに限定され、機密性の高い個人情報は含まれません。

脆弱性が生まれる理由

バグによるもの
チェック機能不足

ディレクトリトラバーサル

アクセスを想定していないディレクトリに不正アクセスするサイバー攻撃

Origin (オリジン)

ウェブコンテンツのオリジン (Origin) は、ウェブコンテンツにアクセスするために使われる URL の スキーム （プロトコル）、 ホスト （ドメイン）、 ポート番号 によって定義されます。スキーム、ホスト、ポート番号がすべて一致した場合のみ、 2 つのオブジェクトは同じオリジンであると言えます。

ダウンロード.png

オリジン間リソース共有 (CORS)

オリジン間リソース共有 (Cross-Origin Resource Sharing, CORS) は、追加の HTTP ヘッダーを使用して、あるオリジンで動作しているウェブアプリケーションに、異なるオリジンにある選択されたリソースへのアクセス権を与えるようブラウザーに指示するための仕組みです。ウェブアプリケーションは、自分とは異なるオリジン (ドメイン、プロトコル、ポート番号) にあるリソースをリクエストするとき、オリジン間 HTTP リクエストを実行します。

コンテンツセキュリティポリシー (CSP)

コンテンツセキュリティポリシー( CSP ) は、クロスサイトスクリプティング ( XSS ) やデータインジェクション攻撃などの特定の種類の攻撃を検出して軽減するのに役立つ追加のセキュリティレイヤーです。これらの攻撃は、データの盗難からサイトの改ざん、マルウェアの配布まで、あらゆる目的で使用されます。

SP を有効にするには、HTTP ヘッダーを返すように Web サーバーを構成する必要があります

Content-Security-Policy

。

クロスサイトスクリプティング（XSS）

Web サイトの脆弱性を利用し、記述言語である HTML に悪質なスクリプトを埋め込む攻撃です。

脆弱性がある Web サイトに罠が仕掛けられる
ユーザーが Web サイトへアクセス
ユーザーのブラウザで不正なスクリプトが実行される
情報漏洩やマルウェア感染が発生

署名(電子署名、デジタル署名)

コンピュータの世界のハンコ（のひとつ）

誰が作ったよ～
改ざんされてないよ～

を示すためにファイルにくっつけるデータです。

電子証明書やタイムスタンプによって本人証明・非改ざん証明が担保されるため不正を防止することができます。

送信されてきたデータが間違いなく本人のものであるのかを証明するのための技術です。

暗号化

元データを変換して第三者が情報を閲覧できない状態を作れるため、セキュリティ対策として有効な方法。

元となるデジタルデータを違う文字列のデータに変換し、解読できない状態にすることです。他者が簡単に閲覧できないような状態にするのが暗号化の目的です。暗号化したデータは元の状態に戻せることが重要で、元のデータに戻す操作は復号といいます。暗号と復号は必ずセットで使用されます。

暗号化の仕組み.png

セッション認証

セッション認証は、ユーザーが一度ログインした後、後続のリクエストでユーザーを識別する方法です。

ユーザーはブラウザを通じて ID とパスワードを含むログイン要求をサーバーに送信します。
サーバーは提供された認証情報を検証し、正しい場合はセッションを確立します。セッション情報はサーバーと Cookie の両方に保存されます。この例ではメモリに保存しますが、実際のアプリケーションではデータベースやその他のストレージを使用するのが一般的です。
サーバーは、セッションが確立されたことを示す応答をブラウザに返します。
ブラウザは、ユーザーが認証されていることを示すセッション情報を含むリクエストをサーバーに送信します。
サーバーはリクエストに含まれるセッション情報を検証し、ユーザーを認証します。
サーバーはブラウザに応答を返し、ユーザーが承認され、特定のアクションまたはリソースへのアクセスが許可されていることを示します。
ユーザーがログアウトを要求すると、ブラウザはサーバーにログアウト要求を送信します。
サーバーはサーバーと Cookie からセッションを削除し、セッション情報を無効にします。
サーバーは、セッションが正常に終了したことを示す応答をブラウザに返します。

トークン

セキュリティトークンは「使い捨てパスワード払い出し器」です。

プログラミングの分野で出てくるトークンは「

ソースコード（人間語で書いたプログラムの元ネタ）の内容を、それぞれが意味を持つ最小単位に分けたもの」です。

言葉で説明されてもピンと来ないかもしれませんが、実際に例を見れば分かると思います。

例えば、そうですね。

以下の処理がありました。

goukei = tanka * suuryou;

この処理における

・goukei

・=

・tanka

・*

・suuryou・;

が、それぞれトークンです。

この場合のトークンは「単語」とか「字句」のようなニュアンスですかね。

ペイロード

パケット通信においてデータ本体を指す。

公開鍵

通信を暗号化するときに使うキーのこと。

秘密鍵

対になる公開鍵で暗号化された通信を復号化するために使うキーのこと。

対称鍵暗号

暗号化と復号化に同じ鍵を使用する暗号化方式。

対称鍵暗号のメリットは、次のとおりです。

暗号化と復号化のプロセスが比較的簡単で速い
高速な処理が可能

共通鍵暗号方式

暗号化と復号に同じ鍵を使う暗号方式。

1.　送信者は共通鍵を使って平文を暗号化する

2.　受信者は共通鍵を使って暗号文を復号化する

共通鍵暗号方式では演算が比較的シンプルなことから、暗号化と復号における高速な処理を実現する。

しかし、お互いに保持している共通鍵が外部に漏えいしてしまうと、実質的に暗号化した内容が読み取りされてしまう恐れがある。このように、鍵を秘密にする必要があることから、秘密鍵暗号方式という別称もある。

非対称鍵系暗号

公開鍵と秘密鍵のペアを使用する暗号化技術。

非対称鍵系暗号の仕組みは次のとおりです。

ユーザーは秘密鍵を持ち、公開鍵を生成します。
公開鍵は誰でも利用できますが、秘密鍵は機密情報として保持されます。
公開鍵で暗号化されたデータは、対応する秘密鍵でのみ復号化できます。

非対称鍵系暗号は、対称鍵暗号（共有鍵暗号）と異なり、暗号化と復号化に異なる鍵を使用します。そのため、鍵を保持する側と鍵を使用する側が同じ鍵を共有する必要がありません

公開鍵暗号方式

公開鍵暗号方式では 2 つの鍵を利用してデータのやり取りを行います。

****

受信者が秘密鍵を使って公開鍵を作成する
送信者は受信者の公開鍵を取得する
平文(暗号化したい文)を送信者が公開鍵を使い暗号化し送付する
受信者が暗号文を受け取る。
受信者は暗号文を秘密鍵で平文に復号化する

このように、受信者（秘密鍵を持っている人）のみが暗号を解くことができる仕組みになっています。

秘密鍵は受信者が大切に保管し、公開鍵は誰でも取得できる場所に公開されています。

ID トークン

68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f3130363034342f39303837346561312d323336332d623238332d663133372d3434633735316533653137612e706e67.png

ユーザー認証情報を含む改ざん検知用の署名付き Token であり、JWT（JSON Web Token）フォーマットでエンコードされています。ID トークンは JWT の一種です。

eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogImlz
cyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4
Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAi
bi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEz
MTEyODA5NzAsCiAibmFtZSI6ICJKYW5lIERvZSIsCiAiZ2l2ZW5fbmFtZSI6
ICJKYW5lIiwKICJmYW1pbHlfbmFtZSI6ICJEb2UiLAogImdlbmRlciI6ICJm
ZW1hbGUiLAogImJpcnRoZGF0ZSI6ICIwMDAwLTEwLTMxIiwKICJlbWFpbCI6
ICJqYW5lZG9lQGV4YW1wbGUuY29tIiwKICJwaWN0dXJlIjogImh0dHA6Ly9l
eGFtcGxlLmNvbS9qYW5lZG9lL21lLmpwZyIKfQ.rHQjEmBqn9Jre0OLykYNn
spA10Qql2rvx4FsD00jwlB0Sym4NzpgvPKsDjn_wMkHxcp6CilPcoKrWHcip
R2iAjzLvDNAReF97zoJqq880ZD1bwY82JDauCXELVR9O6_B0w3K-E7yM2mac
AAgNCUwtik6SjoSUZRcf-O5lygIyLENx882p6MtmwaL1hd6qn5RZOQ0TLrOY
u0532g9Exxcm-ChymrB4xLykpDj3lUivJt63eEGGN6DH5K6o33TcxkIjNrCD
4XB1CKKumZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs-rDaQzUHl
6cQQWNiDpWOl_lxXjQEvQ

先頭から順に、ヘッダー、ペイロード (本文)、署名、を表しています。つまり、ID トークンは形式的には次のような形になっています。各部分は Base64URL でエンコードされています。

ヘッダー.ペイロード.署名;

JSON Web Token(JWT)

JSON オブジェクト内の key-value のペアで表されるデータの集合のことです。JWE の

Ciphertext

もしくは JWS の

Payload

にその値を設定します。key-value のペアで表されるデータのことをクレームと言います。

クレームは RFC 7519 であらかじめ定義されたものがいくつか存在しますが、定義されたもの以外のクレームを自作して設定することも可能です。

JSON 形式で表現されたクレーム (claim) の集合を、JWS もしくは JWE に埋め込んだもの。

制約のある HTTP ヘッダやクエリパラメータに JSON データをうまく付与できるようにすることです。

主に役割は 2 つあります。

JSON データをURL セーフ(Base64URL でエンコード)にする
JSON データをコンパクトにする

デコードしデータの中身を変更し再度エンコードすれば簡単に中身を改ざんできてしまいます。

JWT(JSON Web Token)

トークンベースの認証では、アプリケーションはユーザーのログイン状態を保持しません。

ユーザーは、ログインしたい時や情報を得たいときなど、アプリケーションに HTTP リクエストを送ります。その時に、事前に発行された JWT(=トークン)を、1 つ 1 つのリクエストに毎回一緒に含めて送ります。そしてアプリケーション側はリクエストを受け取る度にその JWT が有効かを検証することで、登録されているユーザーからのリクエストなのかを確認することができる、という仕組みです。

1. ユーザーログインリクエスト:

ユーザーは、特定のリクエストを通じて電子メールとパスワードをサーバーに送信してログインします。

2. 資格情報の検証:

サーバーは、提供された資格情報を保存されているユーザーデータと照合します。

3. トークン生成:

検証が成功すると、サーバーはトークン (通常は JWT - JSON Web Token) を作成します。このトークンには、user_id、権限などのユーザー情報 (クレーム) が保持されます。

4. トークンの署名とハッシュ化:

トークンは秘密鍵で署名され、ハッシュアルゴリズム (SHA256 など) で処理されてハッシュが作成されます。

5. トークンの送信:

サーバーはこのトークンをクライアントに送信し、クライアントは通常それをブラウザに保存します。

6. トークン保管オプション:

クライアントは、HttpOnly Cookies、セッションストレージ、ローカルストレージなどのさまざまな方法でトークンを保存できます。JavaScript アクセスを防ぎ、XSS 攻撃に対するセキュリティを強化するため、HttpOnly Cookies に保存することをお勧めします。

7. トークンの有効期限とセキュリティ:

セキュリティを強化するために、トークンには有効期限が設定されていることがよくあります。

8. リクエストにトークンを含める:

サーバーへのリクエストごとに、クライアントは Authorization ヘッダーでトークンを送信します。

トークンの前に「Bearer」を付けることをお勧めします。

axios.get(URL, {
  headers: {
    Authorization: "Bearer " + token,
  },
});

9. サーバー側の検証:

リクエストを受信すると、サーバーはトークンを取得します。

10. トークンの検証とユーザー認証:

サーバーは秘密キーを使用してトークンを検証し、そこからクレームを抽出します。クレームのユーザー情報がサーバーのユーザーテーブルに存在する場合、サーバーはユーザーを認証し、要求されたリソースへのアクセスを許可します。

主な違い

**保存場所:**セッションはサーバー上に保存され、トークン (JWT) はクライアント側に保存されます。
**ステートフル vs ステートレス:**セッションはステートフルですが、トークンはステートレスであるため、分散システムでのスケーラビリティが向上します。
**有効期限の処理:**セッションの有効期限はサーバーによって管理されますが、トークンの有効期限はトークン自体によって処理されます。
セキュリティ対策: JWT にはデジタル署名や暗号化のサポートが含まれることが多く、Cookie を使用する一般的なセッションメカニズムに比べてセキュリティが強化されていますが、適切に保護されていない場合は CSRF 攻撃に対して脆弱になる可能性があります。
**使用の柔軟性:**トークン (JWT) は、認証を超えた追加情報を伝達する柔軟性が高く、承認やカスタムデータ転送に役立ちます。

JSON Web Signature (JWS)

JWT

が本物か、もしくは中身が改ざんされていないかを検証する仕組みのことです。

暗号鍵を利用して最終的に

ヘッダ.ペイロード.シグニチャ

で形成された文字列を生成します。

元のデータが JSON 形式であることは JWE と同様ですが、コンテンツを暗号化ではなく署名したものです。

BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)

Protected Header 署名に使用するアルゴリズム
Payload コンテンツ
Signature 署名署名の対象は
```
Header
```
と
```
Payload
```
。ふたつを
```
.
```
で繋げた
```
Header.Payload
```
に対して署名を行う

元のデータを base64url (RFC 4648, 5. Base 64 Encoding with URL and Filename Safe Alphabet) でエンコードしたものだということが分かります。ということは、base64url でデコードすると、元のデータが得られます。

JSON Web Encryption (JWE)

この形式は、ID トークンを暗号化したいときに利用されます。

ヘッダー.キー.初期ベクター.暗号文.認証タグ;

BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' ||
BASE64URL(JWE Initialization Vector) || '.' ||
BASE64URL(JWE Ciphertext) || '.' ||
BASE64URL(JWE Authentication Tag)

Protected Header 暗号化に使用するアルゴリズム
Encrypted Key 暗号化に使用した共通鍵コンテンツ暗号化キー(CEK)と言い、暗号化した状態で設定される
Initialization Vector 平文の暗号化に使われる初期化ベクトル
Ciphertext 暗号化したデータ本体
Authentication Tag 暗号文と追加認証データの整合性を保証する認証タグ

暗号化の対象となる平文は、暗号化されたあと、4 番目のフィールドに置かれます。RFC 7516 自体は平文の内容は何でもよいとしていますが、ID トークンの文脈では、平文は「ヘッダー.ペイロード.署名」となります。つまり、JWE の中に JWS が入っている形になります。

OpenID Connect

ID トークンを発行するための仕様である。

SSL/TLS の仕組み

SSL（Secure Sockets Layer）および TLS（Transport Layer Security）は、インターネット上でのデータ通信を暗号化し、セキュリティを確保するプロトコルです。TLS は SSL の改良版で、現在は TLS が主流となっていますが、「SSL」と呼ばれることも多いです。

以下に、SSL/TLS がどのように動作するのかを説明します。

1. 主な目的

SSL/TLS は以下の 3 つを実現するために使用されます：

通信の暗号化データが盗聴されないようにする。
データの完全性データが途中で改ざんされていないことを保証する。
認証サーバー（場合によってはクライアント）の身元を確認する。

2. SSL/TLS ハンドシェイクの流れ

SSL/TLS は通信を始める前に「ハンドシェイク」というプロセスを行い、安全な接続を確立します。このプロセスは以下のステップで進行します：

① クライアントからの接続要求

クライアント（例: Web ブラウザ）がサーバーに接続を要求します。
クライアントは「サポートしている暗号化方式」や「TLS のバージョン」などをサーバーに送信します。

② サーバーの応答

サーバーはクライアントからのリクエストを受け取り、以下を送信します：
- 選択した暗号化方式（例: RSA、ECDHE など）。
- SSL/TLS 証明書（サーバーの身元を証明するデジタル証明書）。
サーバー証明書は、認証局（CA: Certificate Authority）によって署名されており、信頼性が保証されています。

③ 鍵交換

クライアントはサーバー証明書を検証します（例: 証明書の有効期限や署名の有効性を確認）。
クライアントは「セッションキー」を生成するための情報をサーバーに送信します（公開鍵暗号を使用）。
- 暗号方式によっては、サーバーとクライアントが協力してセッションキーを生成します。

④ セッションキーの共有

クライアントとサーバーは共有したセッションキーを使って、今後の通信を暗号化します（共通鍵暗号を使用）。
セッションキーの共有が完了すると、ハンドシェイクが終了し、安全な通信が開始されます。

3. 通信の暗号化

ハンドシェイク完了後、すべての通信データ（例: HTTP リクエストやレスポンス）は、セッションキーを使用して暗号化されます。

これにより、途中で通信が盗聴されたとしても、暗号化されているため内容を解読することはできません。

4. SSL/TLS 証明書の役割

SSL/TLS 証明書は、サーバーの身元を証明するための重要な要素です。証明書には以下の情報が含まれています：

サーバーの公開鍵
サーバーのドメイン名
証明書の発行者（CA）
証明書の有効期限

ブラウザが証明書を検証することで、接続先が正当なサーバーであることを確認します。

5. 主な暗号技術

SSL/TLS では、以下の暗号技術が組み合わされています：

公開鍵暗号（RSA、ECDHE など）：セッションキーの共有に使用。
共通鍵暗号（AES、ChaCha20 など）：通信データの暗号化に使用。
ハッシュ関数（SHA-256 など）：データの完全性を確認するために使用。

6. TLS のバージョン

TLS には複数のバージョンが存在し、セキュリティの観点から最新版を使用することが推奨されます：

TLS 1.0/1.1（非推奨）古いバージョンで、脆弱性が見つかっているため使用は避けるべき。
TLS 1.2（広く使用されている）セキュアな通信の標準として現在も利用されている。
TLS 1.3（最新）ハンドシェイクのプロセスが簡略化され、セキュリティと速度が向上。

7. SSL/TLS の利用例

HTTPS：Web ブラウザとサーバー間の通信。
電子メール：SMTP や IMAP などの暗号化。
VPN：仮想プライベートネットワークのトンネリング。

まとめ

SSL/TLS は、インターネットで安全にデータをやり取りするための基本技術です。通信の暗号化やサーバーの認証、データの完全性を保証することで、盗聴や改ざん、フィッシング攻撃などを防ぎます。特に TLS 1.3 を利用することで、より安全で高速な通信が実現可能です。

基礎

認証

認可