@kanade_lab
なので今の用途で気を使わないといけないのは、共通鍵暗号方式の自動選択の仕組みで、DESとか腐った暗号方式を使わないようサーバ側の設定を確認するぐらいだけど、今の実装でそんなトンチキなことするやつはいないので、何も気にしなくていいよという結論
@kanade_lab
なので今の用途で気を使わないといけないのは、共通鍵暗号方式の自動選択の仕組みで、DESとか腐った暗号方式を使わないようサーバ側の設定を確認するぐらいだけど、今の実装でそんなトンチキなことするやつはいないので、何も気にしなくていいよという結論
@kanade_lab
TLSの仕組みは、
・高速な共通（対称）鍵暗号を使いたい
・共通鍵を安全に交換する仕組みが必要
・片方は公開しなければならない
・なので非対称暗号にして公開鍵だけ表に出す
・でもその公開鍵が正当なものかを検証する仕組みが必要
・改竄防止のためにハッシュをつけた
・公開鍵を発行した人が正当かどうかを保証するために認証局を作った
・認証局まで正当につながることを保証するためにルート証明書がある
・万が一管理をミスった時のために失効リストがある
というとっても迂遠な仕組みなわけだけど、内部通信の暗号化なら1行目以外すべて雑でいいので気を使わなくていいという話
@kanade_lab
もしかしたらindex.txtとかは無いとソフト仕様上のエラーが出るやつかもだけど、失効リストとかはまあ確実に要らない
@kanade_lab
ぶっちゃけそれ全部、証明書自体の信頼性を保証しないといけない公開サービスだからいるものであって、バックエンドで使うなら一対の証明書ファイルができあがれば他はいらない
極端な話共通鍵暗号でもいいし鍵交換の考慮もいらないんだけどそれはともかく
@kanade_lab
こうしたほうがいいとかいうのは公開鍵暗号の強度オプションとかぐらいで、後はもうテンプレのはず
@kanade_lab こんな感じで、オレオレCA作ってサーバ証明書とクライアント証明書作るやつ？
https://kiririmode.hatenablog.jp/entry/20160612/1465694388
@kanade_lab キャッシュ機能全部切ったnginxで一旦受けてそいつにTLS機能全部丸投げする手も考えられるけど
@kanade_lab それバックエンドサーバ側のhttpdの実装の問題でしかないけど、TLS機能ついてないnodejsの組み込みhttpdとかいうやつ？
こしは少し硬めで
淡黄だちたる麺の薄くたなびきたる
https://mastodon.zunda.ninja/@zundan/101813809965157324
@kanade_lab 何しようとしてるかによるというか…ただ単に通信路の暗号化だけならSSHのポート転送でいいんだけど