Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

web/security 以下を md へ一括変換 #7918

Merged
merged 2 commits into from
Aug 25, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
62 changes: 0 additions & 62 deletions files/ja/web/security/certificate_transparency/index.html

This file was deleted.

49 changes: 49 additions & 0 deletions files/ja/web/security/certificate_transparency/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
---
title: 証明書の透明性
slug: Web/Security/Certificate_Transparency
tags:
- Security
- Web
translation_of: Web/Security/Certificate_Transparency
---
**Certificate Transparency** は、証明書の誤発行を防止し、監視するために設計されたオープンなフレームワークです。新しく発行された証明書は、公開されている、多くの場合独立した CT ログに「記録」され、発行された TLS 証明書の追加のみの暗号的に保証された記録を維持します。

このようにして、認証局 (CA) は、はるかに大きな監視と監督を受けることができます。CA/B フォーラムの*ベースライン要件*に違反するような、潜在的に悪意のある証明書は、より迅速に検出され、失効される可能性があります。また、ブラウザベンダーやルートストアのメンテナは、不信に繋がるかもしれない問題がある CA について、より多くの情報に基づいた決定を下すことができるようになります。

## 背景

CT ログは _Merkle_ ツリーのデータ構造をベースに構築されています。ノードには子ノードの*暗号化ハッシュ*がラベル付けされています。リーフノードには実際のデータのハッシュが含まれています。したがって、ルートノードのラベルは、ツリー内の他のすべてのノードに依存します。

Certificate Transparency のコンテキストでは、リーフノードによってハッシュ化されたデータは、現在運営されている様々な異なる CA によって発行された証明書です。証明書の組み込みは、対数的な O(log n) 時間で効率的に生成・検証できる*監査証明*を介して検証することができます。

Certificate Transparency は、認証局の危殆化 (2011 年の DigiNotar の違反)、疑わしい決定 (2012 年の Trustwave の下位ルート事件)、技術的な発行問題 (マレーシアの Digicert Sdn Bhd による 512 ビットの脆弱な証明書の発行) を背景に、2013 年に初めて実現しました。

## 実装

証明書が CT ログに送信されると、_署名付き証明書のタイムスタンプ_ (SCT) が生成されて返されます。これは、証明書が提出され、ログに追加されることを証明する役割を果たします。

仕様では、準拠サーバは接続時にこれらの SCT を TLS クライアントに提供*しなければならない*とされています。これは、いくつかの異なるメカニズムを介して実現することができます。

- 署名付き証明書のタイムスタンプを直接リーフ証明書に埋め込む X.509 v3 証明書拡張機能
- ハンドシェイク中に送信される `signed_certificate_timestamp` 型の TLS 拡張
- OCSP のステープリング (つまり、`status_request` TLS 拡張) と、1 つ以上の SCT を持つ `SignedCertificateTimestampList` の提供

X.509 証明書の拡張では、含まれる SCT は発行 CA が決定します。このメカニズムを使用する場合、Web サーバを変更する必要はありません。

後者の方法では、必要なデータを送信するためにサーバを更新する必要があります。利点は、サーバオペレータが TLS 拡張/stapled OCSP レスポンスを介して送信される SCT を提供する CT ログソースをカスタマイズできることです。

## ブラウザの要件

Google Chrome では、2018 年 4 月 30 日以降の notBefore 日付を持つすべての証明書の問題に対して、CT ログのインクルードを要求しています。これにより、ユーザーは非準拠の TLS 証明書を使用したサイトを訪問できなくなります。これまで Chrome では、_Extended Validation_ (EV) や Symantec が発行した証明書に対して CT のインクルードが義務付けられていました。

Apple は、Safari や他のサーバがサーバ証明書を信頼するために、さまざまな数の SCT を[必要としています](https://support.apple.com/ja-jp/HT205280)。

Firefox は現在、ユーザーが訪問したサイトの CT ログを確認したり、使用を義務付けたり[していません](https://bugzilla.mozilla.org/show_bug.cgi?id=1281469)。

[Expect-CT ヘッダ](/ja/docs/Web/HTTP/Headers/Expect-CT)を使用して、ブラウザが証明書の透過性の要件を常に実施するように要求することができます (Chrome などでは、証明書の発行日が 4 月以前の notBefore であっても)。

## 仕様

| 仕様書 | ステータス | コメント |
| --------------------------------------------------------------- | ---------- | -------- |
| [Certificate Transparency](https://tools.ietf.org/html/rfc6962) | IETF RFC | |
31 changes: 0 additions & 31 deletions files/ja/web/security/insecure_passwords/index.html

This file was deleted.

29 changes: 29 additions & 0 deletions files/ja/web/security/insecure_passwords/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
---
title: 安全でないパスワード
slug: Web/Security/Insecure_passwords
tags:
- Insecure
- Intermediate
- Security
- Web
- password
- passwords
translation_of: Web/Security/Insecure_passwords
---
HTTP を通じてログインフォームを提供することは、ユーザーのパスワードを暴くための広範にわたる攻撃に対して特に危険です。ネットワークの盗聴者は、ネットワークを覗き見たり、転送によって提供されたページを変更したりしてユーザーのパスワードを盗むことができます。

{{glossary("HTTPS")}} プロトコルは、ネットワーク上での盗聴 (機密性) や改ざん (完全性) といった脅威から、ユーザーのデータを保護できるように設計されています。ユーザーのデータを扱うウェブサイトは、ユーザーを攻撃者から守るために HTTPS を使用してください。 HTTPS を使わなければ、ユーザーの情報 (ログインの資格情報など) が盗まれるのは当たり前になってしまいます。このことを [Firesheep](https://codebutler.github.io/firesheep/) が証明したのは有名です。

この問題を修正するためには、 SSL/{{glossary("TLS")}} 証明書をサーバーにインストールし構成してください。様々なベンダーが無料または有料の証明書を提供しています。クラウドプラットフォームを使用しているのであれば、 HTTPS を有効にする方法を独自に持っているかもしれません。

## パスワードの使い回しに関するメモ

ウェブサイトがユーザー名とパスワードを求めても、実際には微妙なデータを保存しないことがあります。例えば、あるニュースサイトがユーザーが読み返したい記事を保存しても、ユーザーに関する他のデータを保存しない場合などです。ニュースサイトのウェブ開発者は、サイトやユーザーの資格情報を安全にする必要があるとはあまり考えないかもしれません。

残念ながら、[パスワードの使い回しは大きな問題](https://www.lightbluetouchpaper.org/2011/02/09/measuring-password-re-use-empirically/)です。ユーザーは複数のサイト (ニュースサイト、SNS、メールサービス、銀行) で同じパスワードを使用します。つまり、サイトが管理するユーザー名とパスワードに何者かがアクセスしたところで、自分たちに大きなリスクがあると思えなくとも、銀行のウェブサイトでも同じパスワードでログインしているユーザーーにとっては非常に大きなリスクなのです。攻撃者はより賢くなっており、一つのサイトでユーザ名とパスワードの組を盗んだ後には、より金目のあるサイトに同じ組でログインできないか試しているのです。

## 関連情報

- [No More Passwords over HTTP, Please!](https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/) — detailed blog post with more information, and FAQ.

{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}
Loading