タグ

TLSに関するrryuのブックマーク (10)

  • HTTPS 証明書の Common Name の検証がしれっと禁止されていた件について | IIJ Engineers Blog

    開発・運用の現場から、IIJエンジニア技術的な情報や取り組みについて執筆する公式ブログを運営しています。 こんにちは。IIJ Engineers Blog編集部です。 IIJの社内掲示板では、エンジニアのちょっとした技術ネタが好評となって多くのコメントが付いたり、お役立ち情報が掲載されています。 今回は、すでにお気づきの方もいるかもしれませんが、いつの間にか HTTPS 証明書の Common Name の検証が禁止 になっていた件について紹介します。 HTTPS 証明書の検証手続きは、RFC2818 で「Subject Alternative Name があればそれで、なければ Common Name を見よ」となっていました。 If a subjectAltName extension of type dNSName is present, that MUST be used as

    HTTPS 証明書の Common Name の検証がしれっと禁止されていた件について | IIJ Engineers Blog
    rryu
    rryu 2022/09/06
    なぜ禁止なのか理由は明確ではないが、しきりに単純比較はダメと書いてあるので、単純比較が前提のCommon Nameを流用するのではなくドメインの比較が前提の専用の属性を使うべしという感じっぽい。
  • Let's Encryptのルート証明書切替周り(完結編) | おそらくはそれさえも平凡な日々

    tl;dr 驚くべきハックにより旧Androidも引き続き証明書エラーなくサイトを閲覧できそうです いよいよ5/4に標準の証明書チェーンが切り替わります 前回までのおさらい Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる Let's Encryptの証明書切替周りその後 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしています。現在は、IdenTrustのルート証明書(DST Root CA X3)が使われています。 正確に言うと、ISRGは新しい認証局なのでそのルート証明書の普及率も当然低く、中間証明書はIdenTrustのルート証明書でクロスサインされており、それが標準で使われています。標準がDSTになっているだけで、ISRGのルート証明書のチェーンの証明書も指定すれば今で

    Let's Encryptのルート証明書切替周り(完結編) | おそらくはそれさえも平凡な日々
    rryu
    rryu 2021/04/30
    なんというハック…
  • TLS 1.3 開発日記 その3 バージョン - あどけない話

    これは、http2 Advent Calendar 2016の7日目の記事です。 今回はTLSのバージョンについて書きます。TLSのバージョンは、Client Hello と Server Hello を交換することで決めます。 Client Hello TLS 1.3 の Client Hello は、TLS 1.2 と互換性を維持するために、構造が死守されています。 TLS 1.2 の Client Hello の定義はこう: struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-2>; CompressionMethod compression_methods<1..2^8-1>; select (extension

    TLS 1.3 開発日記 その3 バージョン - あどけない話
    rryu
    rryu 2016/12/07
    こんなにつらみのある仕様だったとは。
  • 自堕落な技術者の日記 : Certificate TransparencyでわかったというThawteによるgoogle.com証明書の不正発行??? - livedoor Blog(ブログ)

    は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 2015年9月19日(土)に「Symantec caught issuing rogue Google.com certificates」 という記事が飛び込んできて、認証局、証明書、SSL関係のインシデントだと わくわくして飛びつくわけですが、ざっと読んでみると 大手セキュリティベンダーのSymantecの子会社で低価な証明書の発行サービスをやっている Thawteが、2015年9月14日にgoogle.com、www.google.com用のEV SSL証明書を、Googleに了解なく 不正に発行していたことが、証明書の公開監査記録(Certificate Transparency)によりわかった。 という事のようです。厳格な審査で発行さ

    自堕落な技術者の日記 : Certificate TransparencyでわかったというThawteによるgoogle.com証明書の不正発行??? - livedoor Blog(ブログ)
    rryu
    rryu 2015/09/27
    記録はしているけど記録されたものを使う方をあまり考えていない仕組みっぽい。テストデータにgoogl.com使うアレな人はたまにいるが、よりにもよって証明書発行でとは……
  • 細かすぎて伝わらないSSL/TLS

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 「細かいと言うより長いよね」 はじめに こんにちは。ATS の脆弱性を発見した小柴さんや ATS に HTTP/2 の実装を行っている大久保さんと同じチームの一年目、匿名社員M さんからいじられている新人です。今回ありがたい事に、こういったすごい方々を含めモヒカン諸先輩方より「何か書かないの?」「いつ書くの?」という数々のプレッシャーお言葉をいただきました。 というわけで、SSL/TLS の Session 再開機能に関して書いていこうかと思います。 SSL/TLS は機密性、完全性そして真正性に対して安全な通信を行うための仕組みです。しかし、この仕組みは暗号技術を多用し特に接続において複雑なプロトコルを用い、Client, Se

    細かすぎて伝わらないSSL/TLS
    rryu
    rryu 2015/01/21
    session cacheとsession ticketだけでこれだけ書くとは。
  • 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

    Node-v0.10.34がはまったクロスルート証明書とOpenSSLの落とし穴 - ぼちぼち日記
    rryu
    rryu 2014/12/23
    要はOpenSSLがクロスルート証明書に対応していなかったという悲しい話なのか…
  • 『証明書を無料で発行、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ユーザである。ちょっと調べてからコメントすればいいのに。 下記のほう

    『証明書を無料で発行、HTTPSの導入を支援する「Let's Encrypt」』は何に使え、何に使えないのか - いろいろやってみるにっき
    rryu
    rryu 2014/11/21
    DVとOVの証明書の区別が付けづらい現状で始めるのは混乱の元な気がする。
  • 自堕落な技術者の日記 : POODLE攻撃について本当にTLSv1.0なら安全なのか? - livedoor Blog(ブログ)

    は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 POODLE攻撃は、運用泣かせというか、SSLv3のサポートを当に切っちゃっていいのか、レガシークライアントについて対応するのがいいのか、悩む所ですよね。ShellShock騒ぎさえまだうちでは収束していないのに・・・ POODLE攻撃は、「SSLv3の問題であってTLSv1.0以上では(パディングの方法が違うので)影響が無い」とされていますが、nahiさんからコメントもらって「実装依存だけどTLSv1.0でも危険な実装があるんじゃないの?」ということで、その事を書いてみたいと思います。 今回のPOODLE攻撃については、何が問題でどのようにすれば攻撃できるのかという、詳しい図入りの素晴らしく判りやすい解説をモバゲーさんが 「SSL v3.

    自堕落な技術者の日記 : POODLE攻撃について本当にTLSv1.0なら安全なのか? - livedoor Blog(ブログ)
    rryu
    rryu 2014/10/26
    TLSv1.0ではパディングはパディング長と同じ値で埋めなければならないがそれのチェックは仕様上必須とされていないので、チェックしていない実装があったらPadding Oracleが効いてしまうという話。
  • Yahoo! JAPAN

    Yahoo! JAPANトップページの機能を正しくご利用いただくには、下記の環境が必要です。パソコンでご利用のお客様 Windows:Edge 最新版 / Chrome 最新版 / Firefox 最新版 macOS:Safari 15.0以上タブレットでご利用のお客様 iOS 15.0以降、または、Android5.0以降のOSに標準搭載されたブラウザー ※日国内版として発売されている端末でご利用ください。

    Yahoo! JAPAN
    rryu
    rryu 2014/10/23
    PSPやPS3の内臓ブラウザってTLSに対応していない?
  • SSL/TLS(Part.3)

    セッションが保持する情報とは? いったんセッションが設定されると、セッション内部にはどういった情報が保存されているのだろうか。そのヒントは2つ。まず、セッションの設定はHandshake Protocolにより行われること。そして、セッションは通信相手とのネゴシエーションにより合意した関係であること。この2点から考えれば、セッション内部に保存されている情報の種類は、なんとなく想像がつくはずだ。 セッション識別子 サーバが選択した任意のバイトシーケンス。アクティブセッション状態や再開セッション状態を特定する ピア証明書 対向マシンのX.509v3証明書。この要素はnullになることもある 圧縮アルゴリズム 暗号化に先立って利用されるデータ圧縮アルゴリズム 暗号化アルゴリズム バルクデータ暗号化アルゴリズム(null、DESなど)と、MACアルゴリズム(MD5、SHAなど)を指定する。またハッ

    SSL/TLS(Part.3)
    rryu
    rryu 2014/06/06
    TLSのカレントステート、ペンディングステートについて。
  • 1