![[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だけブラウザ側のクッキー「など！！」に保存してもらうスタイル。 nmap --script ssl-enum-ciphers -p 443 example.com httpサーバなりなんなりのSSL/TLSバージョンの有効無効状態などの詳細な情報を得ることができる。相手サーバのDistとかも可能 悪い事例 †IoT †
怪しいセキュリティ対策 †
公開鍵暗号方式 †
SSL/TLS †まずここ見て †
用語 †
https://stackoverflow.com/questions/31183297/ssl-connect-fails-with-ssl-error-syscall-error 透明性の証明 証明書の誤発行を防ぐ新たな技術 パブリックなSSL証明書は、認証局(CA:Certification Authority)によって発行され、その内容が保証されます。 しかし、近年認証局が不正アクセスを受けて偽のSSL証明書を発行したり、誤って不正な証明書をSSL発行したりという事件がありました。 そこでGoogle社が考案したのが、不正なSSL証明書を早期に発見・検知するための仕組みであるCTを(Certificate Transparency)です。これは、現在RFC6922として規格化され、Google Chrome などが対応しています。 CTは認証局が証明書を発行する都度、全ての証明書発行の証跡を、第三者の監査ログに記載する仕組みです。主に、ウェブサイトの運営者やドメイン名の管理者が、その監査ログサーバ（以下「ログ））を確認することで、自分のドメインに対して不正な証明書や、ポリシー外の認証局からの証明書が発行されていないかを検証することができます。それにより利用者が不正に発行された証明書を信頼することを防止します。 CTはあくまで証明書の信頼性を高めるための追加の仕組みであり、これまでの証明書の検証の仕組みが無くなるわけではありません。 ログに証明書を提供すると、ログからはSigned Certificate Timestamp（SCT）と呼ばれるデータが返されます。SCTは、ログが特定の時間内（「Maximum Merge Delay (MMD)」と呼ばれます）に証明書データが格納されたことを保証するタイムスタンプ情報です。ウェブサーバなどのSSL/TLSサーバはログから取得したSCTを、証明書と一緒にブラウザなどのSSL/TLSクライアントに提示しなければいけません。SSL/TLSクライアントは、証明書とSCTを使って、ログの中にその証明書のデータが登録されているかどうかを確認することができます。 CT対応しなかった場合、Google ChromeでEV SSL証明書では2015年2月以降グリーンバーが表示されなくなり、OV SSLならびにDV SSL証明書では2016年6月以降警告が表示されます。 実はプライマリ・サーバとセカンダリ・サーバの違いは、ゾーン情報をローカルのゾーン情報ファイルから入手するか、ほかのDNSサーバ（プライマリ・サーバ）から入手しているかの違いでしかない。問い合わせ側は特に区別はしない（できない）。リゾルバは、通常は複数のDNSサーバからランダムに選択して利用することになる。 これを自ドメインに対する「オーソリティ（権限）」を持つと表現する。SOAレコードはドメインにおけるオーソリティを記述するレコードである。 ただし、より正確にはオーソリティを持っていると見なされるのは、上位ドメインのゾーン情報で、そのドメインのDNSサーバとして指定されたサーバ（NSレコードに記載されたサーバ）に限られる。ドメイン・ツリーに参加していないサーバが、いかにその情報を知っていると主張しても、外部からはそれが正しい情報かどうか確認できないからだ。 認証のためにCNAMEを指定させることもある。これはホストofijeoirj08uru08r3.google.hostingservice.comみたいなものにダイレクトさせて、そもそも SPF：実際に送られてきたIPに直接、あなたの住所としてありえるものはどれですか？と問い合わせる方法。複数IPから送る可能性があるので、問い合わせはinculdeみたいな形で書かれる。 SPF (Sender Policy Framework)とは、 電子メールの送信元ドメインが詐称されていないかを検査するための仕組みです。 送信側は、あらかじめ自ドメインの権威DNSサーバ上に自ドメインの送信者がメールを外部に向けて送出する可能性のあるメールサーバのIPアドレスの一覧を記述（公開）する。SPFの仕様は、 RFC4408(*1)で定められています。 インターネットでメール送信に使用されるプロトコルであるSMTP (Simple Mail Transfer Protocol)は、 差出人のメールアドレス(Fromアドレス)を自由に設定することが可能です。 このため、 送信元を偽った「なりすましメール」を簡単に送ることができてしまい、 これが迷惑メールに利用されてきました。 SPFは、こうしたメールアドレスにおけるなりすましを防ぐための技術の一つで、 DNSを利用するのが特徴です。 ドメインをSPFに対応させるには、 そのドメインのゾーンデータにSPFレコード(*2)という情報を追加します。 SPFレコードには、 そのドメイン名を送信元としてメールを送ってもよいサーバのIPアドレス等を記述します。 一方、SPFに対応したメール受信サーバは、 メールの受信時にそのメールの送信元となっているドメイン(*3)のSPFレコードを、 DNSで問い合わせます。 送信元のサーバがSPFレコード中で許可されていない場合は、 送信ドメインの詐称が行われたと判断して、 受信を拒否するなどの処理を行います。 つまりSPFは、送信元サーバのIPアドレスとDNSを利用して、 あらかじめ想定された送信元以外からのなりすましメールを検出できるようにする機構で、 より多くのドメインがこの仕組みに対応することで、 その効果が高くなります。 電子メールの送信者偽称を防ぐ送信ドメイン認証技術には、ここで説明する「Sender Policy Framework（SPF）」のほかに、「DomainKeys? Identified Mail（DKIM）」、「Sender ID」など様々な方式が標準化されている。その中でもSPFは、他の方式に比べて既存システムに影響を与えず早期に導入できる点が評価されている。 https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/ SPFでは、送信元のIPアドレスを元に認証を行うため、認証時に送信元ホストが本来の送信元に属していないようなケースでは認証に失敗する。 Sample 6: メールを送信しないドメイン 管理しているドメインが全くメール送信しない場合には、“-all”を利用してその旨を公開できる。example.org. IN TXT "v=spf1 -all" これは面白い BoringSSLはOpenSSLのheartbleedのあとのGoogleによる代替 https://ascii.jp/elem/000/000/908/908495/ パスワードの受け渡し方法 †
DDoS †
OAuth †
踏み台 †bastion hostを直訳すると要塞ホストだが、確かに踏み台は要塞ホストの一種と言える。 ただ、日本語で「要塞ホスト」と書いてしまうと、「踏み台」という意味は読み取れなくなるな。 AWSではbastion hostは踏み台と思えばいいみたい。 所有権確認 †
電子透かし＝ウォーターマーク †
Tink †
エンベロープ暗号化 †
耐性ダンパー性 †あらゆるICカードの安全性は耐タンパー性があってこそ成り立っている マイナンバーカードについて「悪用された場合には直ちにチップが破壊をされるという仕組みになっております」と総務大臣が記者会見で言っていたのだが、本当？チップが破壊されるなんて初めて聞いた。 https://soumu.go.jp/menu_news/kaiken/01koho01_02001178.html MAC randomization †IP アドレスを抜かれてもプライバシー上問題ないの、IPv4 が IP アドレスの個数について楽観的すぎたから？と思ったけど、冷静に考えると IPv6 が普及したら一意になるからどうなってるんだろうだし、そもそも MAC アドレスで所有者特定！みたいな話にならないのなんでだろう（紐づけられないから？） なってるからpixelとかだとmacアドレスをrandomizeしてるんでない？ え、初めて知りました（ということは IPv6 もランダマイズする？と思ったら MAC がランダマイズしてないとまずいよねみたいな実装を発見していました https://networkacademy.io/ccna/ipv6/ipv6-on-windows） X509証明書 †
$ openssl s_client -connect google.co.jp:443 -showcerts </dev/null | openssl x509 -text -noout
Connecting to 2404:6800:4004:825::2003
depth=2 C=US, O=Google Trust Services LLC, CN=GTS Root R1
verify return:1
depth=1 C=US, O=Google Trust Services, CN=WR2
verify return:1
depth=0 CN=*.google.co.jp
verify return:1
DONE
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
74:31:44:5a:51:8c:67:31:12:7a:ec:f8:7c:a7:35:fb
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Google Trust Services, CN=WR2
Validity
Not Before: Feb 3 08:38:16 2025 GMT
Not After : Apr 28 08:38:15 2025 GMT
Subject: CN=*.google.co.jp # 認証局の情報。2025 年現在はホストをここで検証することを禁止するように RFC が制定されつつある。
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:85:73:7c:1f:29:83:ff:df:7a:b7:53:5f:38:9a:
24:7b:18:19:b9:88:59:f3:8a:a4:ec:b4:3d:63:66:
1d:78:d2:e2:5b:ef:32:1f:c3:ad:09:e7:a8:81:38:
56:e8:68:e5:d5:11:cd:71:74:2e:96:d3:64:12:29:
9e:d3:aa:fa:14
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
E6:9E:D0:55:09:41:DB:3F:72:8E:9B:69:22:45:ED:89:6F:28:04:E5
X509v3 Authority Key Identifier:
DE:1B:1E:ED:79:15:D4:3E:37:24:C3:21:BB:EC:34:39:6D:42:B2:30
Authority Information Access:
OCSP - URI:http://o.pki.goog/wr2
CA Issuers - URI:http://i.pki.goog/wr2.crt
X509v3 Subject Alternative Name:
DNS:*.google.co.jp, DNS:google.co.jp
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://c.pki.goog/wr2/oQ6nyr8F0m0.crl
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 4E:75:A3:27:5C:9A:10:C3:38:5B:6C:D4:DF:3F:52:EB:
1D:F0:E0:8E:1B:8D:69:C0:B1:FA:64:B1:62:9A:39:DF
Timestamp : Feb 3 09:38:17.013 2025 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:21:00:F0:74:AC:31:26:E6:26:77:BE:34:62:
A4:F3:8C:07:21:64:A9:5F:E9:6B:03:F3:B6:94:23:92:
1E:C0:43:37:6D:02:20:59:6C:B4:11:FC:E0:02:C1:B4:
E3:74:AD:3B:3F:17:02:B0:6F:3B:66:44:9E:9F:9F:FB:
11:7E:09:16:8B:02:F2
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 13:4A:DF:1A:B5:98:42:09:78:0C:6F:EF:4C:7A:91:A4:
16:B7:23:49:CE:58:57:6A:DF:AE:DA:A7:C2:AB:E0:22
Timestamp : Feb 3 09:38:17.222 2025 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:B7:69:46:0F:D8:C4:05:39:24:28:7C:
7E:F8:57:EE:C7:06:2A:7C:5D:34:F8:C3:09:A1:52:97:
57:E7:B4:71:78:02:21:00:FA:63:63:68:92:9A:5E:D0:
E5:DA:FC:73:7E:B7:D4:8C:DE:A4:F4:6C:E3:45:47:0F:
24:06:B8:C5:D4:E9:0C:CB
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
91:59:da:e6:ed:9e:e7:d6:6a:5f:c8:89:36:3f:22:7a:9e:64:
1b:8c:52:70:2d:5c:0e:c6:58:f6:bb:69:34:b2:c7:24:fe:fb:
55:f3:a4:b0:0e:f5:0e:0c:0e:31:83:4a:02:cf:7f:c0:36:1b:
3c:3c:5f:db:73:5b:80:ed:a3:fd:3e:ea:70:f9:75:db:44:67:
15:5c:c3:9a:46:cd:55:1a:0c:2a:8c:9c:f6:5a:3f:aa:52:2f:
96:8b:8d:28:e9:62:ae:a0:ac:fe:97:19:9c:56:9e:56:68:3f:
d0:88:59:d6:5e:9b:ba:1a:d9:18:d2:29:df:c3:66:15:f4:33:
df:ca:95:08:a7:6f:93:18:a3:c6:8b:75:7a:33:83:f9:77:1e:
3c:b6:2d:d3:95:dd:3d:5a:5e:f3:e0:df:7c:b1:90:77:0c:f9:
05:69:7a:f5:37:16:55:54:a8:f2:f8:be:d9:dd:4b:0e:64:c0:
a1:5d:e4:ed:ac:88:05:fa:d0:56:63:c6:8f:50:92:4e:c7:a4:
b3:5d:af:1b:79:6d:8f:97:61:2e:72:ef:73:3e:85:33:8a:c6:
66:f4:2f:14:11:8a:8f:90:15:6c:0b:2c:a7:a9:1f:b0:5b:3b:
3d:d4:4c:8a:f9:c9:ba:54:cb:9d:7e:f6:9b:a8:a5:9e:06:8a:
63:fa:97:12
|
