![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
概要 †
主な議題 †
雑多 †セキュリティ上では万全ではない（通信を傍受されたりフィッシング詐欺に遭ったりする危険性がある）ようです。それを防ぐ仕組みとしてサーバー側でHTTPSで必ず接続するようにとブラウザに指示するのが、HSTSの設定です。 Hypertext Strict Transport Security（HSTS） HSTSの設定は2回目以降のアクセスについてHTTPのURLをブラウザに打ち込んでも、HTTPSでアクセスさせる仕組みです。 しかし、初回のアクセスについては、HTTPでアクセスすることがあり得るので、セキュリティは万全とはいえない状態です。（万全とはいえないケースについてはこちら） プリロードHSTS そのため、HSTSをさらに確実にするために「プリロードHSTS（Preload HSTS）」という仕組みがあります。なんかめっちゃ頑張ってサーバ側で設定して、サーバからのレスポンスヘッダに一項目追加すると、できる。Apacheでmod_headersが使えるサーバーなら.htaccessかhttpd.confに一行書けばよい。Header set Strict-Transport-Security "max-age=31536000; includeSubDomains?; preload"。 PEM root.pemというのがroot認証のときに必要なものらしい。中身をみると、BEGIN CERTIFICATEのようなやつが書いてあって、あ、これがそうだったのねという感じになるね。 https://www.ecoop.net/memo/archives/guide-for-pem.htmlのようになっていて、これを知っていると、ログでPEM吐いてんなあとわかる。 証明書チェーンの全てを含む場合 テキストエディタで以下のファイルを開き、内容をコピーして .pemファイルに貼り付けます 発行されたサーバー証明書ファイル 中間証明書ファイル root 証明書ファイル .pemファイルには、上記のの順番で貼り付けてください。また、各証明書の開始タグと終了タグを省略することはできませんので注意してください。 x.509 証明書を発行するためのCAの構造を規定する規格 これ読んだほうが良さそう https://securityblog.jp/security_wordlist.html CAは公開鍵が正しいことを保証するもの。 オレオレ証明書は暗号化できているが、改ざんと通信相手が正しい保証が得られない。 Forward Secrecy(あるいはPerfect Forward Secrecy, PFS)は、全ての暗号化された通信を記録しておき、後からある期間の鍵を盗んだことができたとしても、それ以前に記録しておいた通信は復号できないという性質を指す。鍵交換にECDHEまたはDHEを使っている場合はPFSであると言うことができる。なお、ECDHE/DHEのEは"Ephemeral"のEである。 https://qiita.com/harukasan/items/fe37f3bab8a5ca3f4f92 これしっかりしている文章だからちゃんと勉強 クライアントが証明書の正当性確認するプロトコルはOCSP Staplingと呼ばれている。HTTPS通信を行う際には、証明書が失効していないか確認するため、OCSP Responderに証明書の正当性を確認する必要がある。HTTPS通信の度にOCSPリクエストを行わなければならないため、OCSP responderが低速であった場合、大きなボトルネックになる。 TLSの共通鍵通信を可能にするまでの流れを TLSハンドシェイクというらしい cert rotation HTTPSで通信するときに、サーバの証明書交換をdowntimeなしで行うための方法 サーバ側ではサーバ証明書情報を置く必要がある SSLは公開鍵で共通鍵を渡して通信する方法。 セッションはクッキーと似ていますが、必要な情報をクライアントではなくサーバ側に保存します。その為、よりセキュアに利用することができます。ここではセッションの使い方について解説します。 クッキーはサーバがユーザのブラウザのメモリに保存するというスタイル。 セッションは、サーバに必要な情報をメモして、セッションIDだけブラウザ側のクッキー「など！！」に保存してもらうスタイル。 悪い事例 †IoT †
怪しいセキュリティ対策 †
|
