Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

SSLに関するNagataniのブックマーク (13)

  • Symantecが再びGoogleの信頼を失った件についてのメモ - Technically, technophobic.

    (初めに言い訳しておくと、証明書界隈については詳しくないです。某誤訳量産サイトが適当な記事を書いていたので、なにか書かねばと思って書いているという程度のまとめ記事です。間違いなどあればご指摘ください) 何が起こるのか Ryan Sleeviさん(Googleの人)がBlink-devのメーリングリストに投稿したこれにまとまっています:https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ 経緯についてはいったん飛ばして、どのようなアクションが提案されているのか見ます。 To restore confidence and security of our users, we propose the following steps: A reduction in the accepted

    Symantecが再びGoogleの信頼を失った件についてのメモ - Technically, technophobic.
  • プロフェッショナルSSL/TLS

    こちらは改訂前の旧版のページです。改題第2版の商品ページをご覧ください Webセキュリティ解説の決定版 "Bulletproof SSL and TLS" の全訳(原書2017年版へのアップグレード済み) Ivan Ristić 著、齋藤孝道 監訳 520ページ B5判 ISBN:978-4-908686-00-9 電子書籍の形式:PDF 2020年7月4日 第1版第5刷 発行(原書2017年版アップグレード対応済み) サイトにてユーザ登録のうえ購入いただくと、原著改訂第2版に収録されるTLS 1.3の解説章を付録として含んだ特別版PDFがお読みいただけます 現代生活を支えるネットワークにとって、通信の暗号化は不可欠の機能です。しかし、実際のインターネットで暗号化通信を利用できるようにするには、暗号化アルゴリズムの知識だけでなく、セキュリティプロトコルとその実装技術、さらに、基盤となる信

    プロフェッショナルSSL/TLS
  • Let's Encrypt 総合ポータル

    Let's Encrypt 最新情報 ・ワイルドカード証明書と ACME v2 へ対応が完了しました(2018年03月15日 更新) ※技術的な詳細については ACME v2 とワイルドカード証明書の技術情報 をご覧ください。 ※ワイルドカード証明書の取得には、ACME v2 プロトコルに対応したクライアントと DNS による認証が必要です。証明書の取得・更新の際に、DNS の「TXT レコード」にワンタイムトークンを登録する必要があります。 ※サブジェクトの代替名(SAN : Subject Alternative Name)を使用した 複数のドメイン名・サブドメイン名に対して有効な証明書 も引き続き取得可能です。 Let's Encrypt について Let's Encrypt は、認証局(CA)として「SSL/TLSサーバ証明書」を無料で発行するとともに、証明書の発行・インストール・

    Let's Encrypt 総合ポータル
  • 理解してるつもりの 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

    理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 · けんごのお屋敷
  • websec-room.com - websec room リソースおよび情報

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

    Nagatani
    Nagatani 2015/12/01
  • SSL/TLSの基礎と最新動向

    1. SSL/TLSの基礎と最新動向 セキュリティキャンプ 2015 2015年8月12日 IIJ 大津 繁樹 更新版資料の置場 http://goo.gl/cX1M17 Github Repo: https://goo.gl/vRLzrj 2. 自己紹介 • 大津 繁樹 • 株式会社 インターネットイニシアティブ • プロダクト部 アプリケーション開発部サービス開発2課 • NodeJS Technical Committee メンバー • (主にTLS/CRYPTO/OpenSSLバインディングを担当) • IETF httpbis WG で HTTP/2相互接続試験等仕様策定に参画。 • ブログ: http://d.hatena.ne.jp/jovi0608/ 3. はじめに • TLS(Transport Layer Security)の仕組みについて学んでいただき ます。 •

    SSL/TLSの基礎と最新動向
  • SSL証明書ならさくらのSSL|さくらインターネット

    法人・組織のお客様 コーポレートサイトには企業認証(OV)、ECサイトなど個人情報を取り合うサイトにはEV(Extended Validation)認証を利用します。

    SSL証明書ならさくらのSSL|さくらインターネット
  • 華麗なる因数分解:FREAK攻撃の仕組み - ぼちぼち日記

    1. はじめに ちょうど今朝 OpenSSLをはじめとした様々なTLS実装の脆弱性の詳細が公表されました。 この InriaとMSRのグループは以前からTLSのセキュリティに関して非常にアクティブに調査・検証をしているグループで、今回も驚きの内容でした。 このグループは、TLSのハンドシェイク時の状態遷移を厳密にチェックするツールを開発し、様々なTLS実装の脆弱性を発見・報告を行っていたようです。 特にFREAKと呼ばれるOpenSSLの脆弱性(CVE-2015-0204)に関しては、ちょうど修正直後の1月初めに Only allow ephemeral RSA keys in export ciphersuites で見ていましたが、具体的にどのように攻撃するのかさっぱりイメージできず、あのグループだからまた超絶変態な手法だろうが、まぁそれほど深刻じゃないだろうと見込んでいました。 今回

    華麗なる因数分解:FREAK攻撃の仕組み - ぼちぼち日記
  • 細かすぎて伝わらないSSL/TLS

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

    細かすぎて伝わらないSSL/TLS
  • 脆弱性事例に学ぶセキュアコーディング「SSL/TLS証明書検証」編 (KOF2014)

    1. ~誰かの失敗を他山の石に~ 脆弱性事例に学ぶセキュアコーディング 「SSL/TLS証明書検証」編 JPCERT/CC 情報流通対策グループ 戸田 洋三 (yozo.toda@jpcert.or.jp) 1 KOF2014 version 2. Copyright©2014 JPCERT/CC All rights reserved. 自己紹介 http://www.tomo.gr.jp/root/e9706.html JPCERT/CC 情報流通対策グループ 解析チーム リードアナリスト 戸田 洋三 脆弱性情報分析, セキュアコー ディング普及啓発活動…… に努めてます 2

    脆弱性事例に学ぶセキュアコーディング「SSL/TLS証明書検証」編 (KOF2014)
  • SSL 3.0 の脆弱性「POODLE 」とは?

    オンプレミスからクラウドへの移行をはじめ、ハイブリッドクラウド環境をシームレスに保護しながら、クラウドの利点を実現します。 詳しくはこちら

    SSL 3.0 の脆弱性「POODLE 」とは?
  • WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる

    OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO

    WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
  • 無料のSSL証明書StartSSLを活用する - Qiita

    背景 自前のサービスでhttps通信をサポートするには、SSL証明書が必要になります。 自分で使用するだけなら、SSL証明書も自前で作成するいわゆるオレオレ証明書を用いても良いのですが、外部に公開するサービスの場合そうとも行きません。 SSL証明書というと値段が高い印象がありましたが、StartSSLというサービスで無料でSSL証明書の発行を受けられると言うことで試してみました。 StartSSLにユーザー登録する 証明書の発行を行う前に、StartSSLにユーザー登録する必要があります。 StartSSLから、"StartSSL Free (Class1)"を選択します。 Certificate Control Panelを選択。 Sign-upに進みます。 名前、住所、メールアドレスなど 個人情報の登録を行います。 登録したメールアドレスに人確認のメールが届くので、受信したメールのa

    無料のSSL証明書StartSSLを活用する - Qiita
  • 1