TLS徹底演習セキュリティ・キャンプ全国大会2016 集中講義
HTTPS接続の状態をチェックできるGoogle ChromeのSecurityパネル
[レベル: 上級] HTTPSの状態を検証するための「Security（セキュリティ）」パネルがGoogle Chromeのデベロッパーツールに追加されました。 Securityパネルでは、次の3項目の安全性を知ることができます。 証明書: 有効なTLS/SSL証明書が使用されているかどうか TLS接続: 安全なTLS/SSL接続が確立されているかどうか リソース: 画像やJavaScriptなどのリソースもTLS/SSLで配信されているかどうか Securityパネルのレポート具体例 SecurityパネルでHTTPSの状態がどのようにレポートされるかの具体例をいくつか見てみましょう。 まずChromeのデベロッパーツールを立ち上げます。 [Google Chromeの設定]（右上の3本バー） − [その他のツール] − [デベロッパー ツール] Ctrl + Shift + i (Wi
理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 · けんごのお屋敷
apache や nginx の設定をしたことがあれば以下の様な行を見たことがある人も多いのではないでしょうか。(※ 下記は nginx の設定。apache の場合は SSLCipherSuite です。) ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; これが暗号スイートを指定している箇所です。そしてこの部分、わけのわからない文字列の羅列なのですごく取っつきにくくて何を指定したらいいかわからないので、コピペしてしまう人も多いんじゃないでしょうか。かくいう私も数年前に趣味で TLS 対応の Web サービスを作った時はコピペで済ませていました。この暗号スイートは、以下のような OpenSSL のコマンドを使って対応している一覧を見ることができます。 $ openssl ciphers -v AES128-SH
公開鍵暗号 - RSA - 基礎 - ₍₍ (ง ˘ω˘ )ว ⁾⁾ < 暗号楽しいです
2018/10/22 全体的に問題があったので書き直した. 内容はほぼ変わっていない. 本記事では, 世界で最初に提案された公開鍵暗号であるRSA暗号の基礎事項について解説する. RSA暗号の動作原理について示した後, 簡単な攻撃手法の一覧を載せる. 公開鍵暗号 暗号理論, 特に現代暗号における暗号は「秘密鍵暗号(Secret-key Cipher)」, 「公開鍵暗号(Public-key Cipher)」の2種類に大分される. 秘密鍵暗号はよく知られている通り「秘密の鍵$k$を事前に共有しておき, その鍵を用いて暗号化・復号を行う暗号方式」である. これに対して公開鍵暗号は「暗号化に用いる鍵$k _ {enc}$, 復号に用いる鍵$k _ {dec}$が存在し, 暗号化・復号のそれぞれで異なる鍵を用いる暗号方式」と定義され, このうち$k _ {enc}$は一般に公開されることが多いこと
TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
細かすぎて伝わらないSSL/TLS
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 「細かいと言うより長いよね」 はじめに こんにちは。ATS の脆弱性を発見した小柴さんや ATS に HTTP/2 の実装を行っている大久保さんと同じチームの一年目、匿名社員M さんからいじられている新人です。今回ありがたい事に、こういったすごい方々を含めモヒカン諸先輩方より「何か書かないの？」「いつ書くの？」という数々のプレッシャーお言葉をいただきました。 というわけで、SSL/TLS の Session 再開機能に関して書いていこうかと思います。 SSL/TLS は機密性、完全性そして真正性に対して安全な通信を行うための仕組みです。しかし、この仕組みは暗号技術を多用し特に接続において複雑なプロトコルを用い、Client, Se
TLS(SSL)のハンドシェイクの安全性について - きままにものづくり
今年は色々と問題のあったTLSについてです。 この記事では、TLSがどうのような暗号技術を用いてセキュアな通信を実現しているのかを説明します。 TLSとは TLSとはTransport Layer Securityのことであり、現在は1.2が最新のバージョンで1.3を策定しているところです。 TLSが実現したいのはセキュアな通信の確立です。セキュアな通信とは以下の3つの性質を満たす通信のことです。 通信内容を秘匿できる 通信内容の改竄を検知できる 通信相手を特定できる これらの性質を暗号技術を組み合わせることで実現します。詳しい実現方法は後で説明します。 TLSは大きく、Record layerとハンドシェイクの2つに分かれます。Record layerでは共通鍵暗号を、ハンドシェイクでは公開鍵暗号を主に用いています。 ハンドシェイクで、上の1,2,3の全ての性質を満たしながら秘密情報の共
Node-v0.10.34がはまったクロスルート証明書とOpenSSLの落とし穴 - ぼちぼち日記
既に12月22日ですが、このエントリーは、Node.js Advent Calendar 2014の13日目のエントリーです。 いや私が書くの遅れたわけじゃないですけど…(言い訳)、ちょうどタイムリーなネタがあるので、先日リリースされたNode-v0.10.34で発生した（現在も継続している）問題について携わった経緯を自分の目線で書いてみます。 追記：日本時間の12/24にNode-v0.10.35がリリースされました。 http://blog.nodejs.org/2014/12/23/node-v0-10-35-stable/ 本記事の不具合も修正されています。 1. Node-v0.10.34リリース直後にissue発生 先週12/17にNode v0.10.34 (Stable)がリリースされました。10月中旬にPOODLE騒ぎでOpenSSLに対応した Node-v0.10.33
HTTP/2から見えるTLS事情 - あどけない話
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
SSLv3脆弱性「POODLE」、TLSにも影響--グーグルの専門家が指摘
Googleに所属するSSL専門家のAdam Langley氏は米国時間12月8日、自身のブログで多くのTLS実装に対して警告を出した。以前明らかになった、SSLバージョン3（SSLv3）に影響する「POODLE（Padding Oracle On Downgraded Legacy Encryption）」攻撃と同じような攻撃につながる脆弱性を含んでいるという。 SSLv3は、CBCモードの暗号でデータのパディングを効果的に特定しない。そのため、ブロック暗号の整合性をきちんと確認できず、「パディングオラクル攻撃」を可能にしてしまう。SSLv3の後、仕様はTLSと改名され、バージョン1になった。TLSv1の変更点の1つとして、パディングオラクル攻撃を防ぐためのパディング処理を改善した。 だが、TLS実装でもパディングバイトのチェックは完全ではないという。多くのTLS実装がSSLv3ソフトウ
複数のWebサーバでSSLセッションキャッシュを共有してSSL処理を高速化(Apache + mod_ssl + mod_socache_memcache) - 元RX-7乗りの適当な日々
HTTPS(SSL利用)サイトがSEO的に優遇されるトレンドで、世間的にもHTTPS接続でサイト運用するサービスが増えてきています。 これが、ハイトラフィックサイトになってくると、このフロントエンドでSSL処理させることが負荷的にもなかなか辛いのです。 で、Apache 2.3以降では、Shared Object Cache Providerとして、memcachedが選択できるようになっています。 この仕組みを利用して、Apacheとmemcachedを並べることで、各サーバでユーザのSSL Session Cacheを共有しながらHTTPSリクエストを負荷分散できる構成を作ってみました。 WebサーバでSSLオフロード 常時SSLを利用したWebサイトを運用するために、SSLアクセラレータといったアプライアンス製品だとか、ソフトウェアだとApacheやNginxのSSLモジュールを使う
『証明書を無料で発行、HTTPSの導入を支援する「Let's Encrypt」』は何に使え、何に使えないのか - いろいろやってみるにっき
やっと、ついに、誰もが無料でHTTPSを使えるようになる！…MozillaやEFFが共同プロジェクトを立ち上げ - TechCrunchだが、ブコメ欄で「フィッシングサイトが見分けられなくなる」と勘違いしている向きがあるようなので、ちょっと書いておく。 このLet's Encryptだが、Let’s Encrypt: Delivering SSL/TLS Everywhereに説明が書かれている。そもそも上のTechCrunchの記事ではLet's Encryptがどういうものか分からない。この記事では何ができて何ができないかを書いていないし。 TechCrunchの記事はオレが見た時点(2014/11/20 5:00)ですごいブクマ数(792ユーザ)なんだけど、本体の説明のブクマ数は4ユーザ、オレがブックマークしたので5ユーザである。ちょっと調べてからコメントすればいいのに。 下記のほう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
証明書を無料で発行、HTTPSの導入を支援する「Let's Encrypt」2015年夏開始 EFFやMozillaなどが参加
脆弱性事例に学ぶセキュアコーディング「SSL/TLS証明書検証」編 (KOF2014)
