Open2023/11/09にコメント追加3

【メモ】ネットワーク

FQDN: Fully Qualified Domain Name (完全修飾ドメイン名)

インターネット上でホストを一位に識別するために利用される。
ホスト名とドメイン名を組み合わせた文字列を使用し、以下の形式で表現される

ホスト名.サブドメイン名.トップレベルドメイン

例: 「www.example.jp」の場合
ホスト名: www
サブドメイン名: example
トップレベルドメイン: jp

参考

作りながら学ぶWebシステムの教科書 P222

あぷし

HTTPS通信

SSL/TLS

インターネット通信を暗号化するための通信プロトコル。
共通鍵暗号方式と公開鍵暗号方式を組み合わせて使用する。

SSL: Secure Sockets Layer
TLS: Transport Layer Security

Webページの改ざん防止

メッセージ認証を用いて検証する。
TLSネゴシエーションのシーケンス中に公開鍵暗号方式を用いてクライアントとサーバーで共通鍵を共有し、共通鍵を使用してセッション鍵を生成する。

サーバー側はメッセージのハッシュを共通鍵で暗号化し、MAC(Message Authentication Code)を生成する。メッセージと生成したMACをクライアントに送信する。
クライアントはサーバーから受け取ったMACを共通鍵で復号する。また、クライアントはサーバーから受け取ったメッセージのハッシュを取り、復号したMAC値から取り出したサーバー側で計算したハッシュ値と内容を比較する。ハッシュ値が同一であれば改ざんされていないことが証明できる。

証明書の種類

証明書は 認証局(CA: Certification Authority) と呼ばれる電子証明書を発行する第三者機関により発行される。

名称	役割	発行者	格納場所
サーバー証明書	・サーバーが本物であることを証明する	中間認証局	Webサイトを運用するサーバー
中間CA証明書	・中間認証局の正当性を証明する・サーバー証明書を検証する	ルート認証局	Webサイトを運用するサーバー
ルート証明書	・ルート認証局の正当性を証明する・中間CA証明書を検証する	ルート認証局	Webブラウザ

証明書の構造

ここを見る。

主な構成要素は以下

発行者
主体者
公開鍵
署名
- 秘密鍵でメッセージのハッシュを基に署名を作成する。
- 公開鍵で署名を検証する。

自己署名証明書

プライベート認証局を立ち上げて(opensslコマンドなど)発行者の自身で署名を行う証明書 = 自己署名証明書 (a.k.a オレオレ証明書)
その場合、プライベート認証局の証明書をWebブラウザにインストールすることでルート証明局として偽装が可能。

Let's Encrypt

自動で証明書を発行してくれる便利なサービス。
certbotをインストールして発行。
有効期限は90日だが、有効期限の30日前に自動更新してくれるデーモンが動いてくれる。

中間CA証明書の格納ディレクトリ (Ubuntu)

/usr/share/ca-certificates/: 信頼されるべきものは /etc/ca-certificates.conf で選択される
/etc/ssl/certs: /usr/sbin/update-ca-certificatesコマンドで ↑ からシンボリックリンクが貼られる

証明書の内容確認

opensll x509 -text -nout -in <証明書ファイルのパス>

WebサーバーのHTTPS化

サーバー証明書をWebサーバー(Apache, Nginxなど)にインストール
リバースプロキシでクライアントからの HTTPSリクエストを代理応答
- リバースプロキシ - Webサーバー間の通信はHTTPで行う
Webアクセラレータやロードバランサーを配置

参考

作りながら学ぶWebシステムの教科書 Chapter 6-2
opensslコマンドで証明書情報を確認したい
/usr/share vs /usr/local/share: Where to install CA certs?
独自(root)CA のインストール方法
サーバー証明書／中間CA証明書／ルート証明書の違いとは？ | さくらのSSL
図解 X.509 証明書 - Qiita

あぷし

ETag

HTTPのレスポンスヘッダーの一つ。ある特定のリソースのバージョンを表す識別子。
ETag:に続けてリソースを一意に識別する値を設定する。
ETagの値には以下のようなものが使用される

コンテンツのハッシュ
最終更新タイムスタンプのハッシュ
リビジョン番号

例

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"

値の先頭にW/が付与されている場合は弱い検証を行うETagとして扱う。
付与されていない場合は強い検証を行うETagとして扱う。

検証

強い検証

サーバー・クライアント双方で、データ1バイトも違わない完全一致の状態であることを意味する。

弱い検証

データは完全に一致していないが、リソースの意味合いとしては同じとみなすことができる場合を意味する。
Webページなどで広告などがアクセスのたびに差し替わるが、リソースとしては同じである場合などに用いられる。

使い方

Wikiなどの同時編集の衝突防止

ETagとIf-Matchヘッダを使用して編集の空中衝突を検出できる。

変更されていないリソースのキャッシュ

ユーザーが指定されたURLを再度訪問したとき、コンテンツが古くなったものであった場合、クライアントはIf-None-MatchヘッダーでETagの値を送る。(条件付きリクエスト)
サーバーは、クライアントのETagを現在のETagと比較して、両者が一致する場合は「304 | Not Modified」を本文なしで返却、キャッシュされたレスポンスのバージョンがまだ使用可能であることをクライアントに通知する。

コンテンツの更新を検証するために、最終更新日時を用いるケースもある。その場合、サーバーはLast-Modifiedレスポンスヘッダーを使用し、クライアントはIf-Modified-Sinceヘッダーを用いる。

参考

ETag - HTTP | MDN
Web API: The Good Parts | 4.3 キャッシュとHTTPの仕様 P117