![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
[[FrontPage]] *概要 [#vf109c7f] -手紙の内容を誰にも見られたくない。でもこれを見知らぬ誰かに送りたい。これを極めた形がセキュリティ --手紙を想定すると結構いろいろうまく行く *主な議題 [#i6dca174] -傍受 -なりすまし -改ざん *雑多 [#w54c7c74] セキュリティ上では万全ではない（通信を傍受されたりフィッシング詐欺に遭ったりする危険性がある）ようです。それを防ぐ仕組みとしてサーバー側で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だけブラウザ側のクッキー「など！！」に保存してもらうスタイル。 *悪い事例 [#lc64db9c] **IoT [#xae7d42f] -スマートキーの弱点突く車盗難 微弱電波中継し解錠 -Amazon Bottonは何も入っていないように見えるけど、セキュリティは死ぬほど頑張っている -そうかグーグル翻訳は「情報の修正を提案」で調教できるんだ -ぐーぐるほんやくがViginal cum shotになった時期がある **怪しいセキュリティ対策 [#a48b7425] -パスワード別送 --日本のガラパゴスルール --日本国内の認定制度である「プライバシーマーク」を取るために、2010年から「添付ファイルに対するセキュリティ対策」が必要 --既存システムへの変更不要な方法として、反証困難な別送方式を取ったと予想できる --盗聴対策には効果がなし、誤送信を防ぐ能力はある --添付ファイル付きメールとパスワード通知メールを、システムで自動的に同じ相手に送るような運用があるらしいがこれはマジでセキュリティ的に意味がない |
