理解してるつもりの 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
華麗なる因数分解:FREAK攻撃の仕組み - ぼちぼち日記
1. はじめに ちょうど今朝 OpenSSLをはじめとした様々なTLS実装の脆弱性の詳細が公表されました。 この InriaとMSRのグループは以前からTLSのセキュリティに関して非常にアクティブに調査・検証をしているグループで、今回も驚きの内容でした。 このグループは、TLSのハンドシェイク時の状態遷移を厳密にチェックするツールを開発し、様々なTLS実装の脆弱性を発見・報告を行っていたようです。 特にFREAKと呼ばれるOpenSSLの脆弱性(CVE-2015-0204)に関しては、ちょうど修正直後の1月初めに Only allow ephemeral RSA keys in export ciphersuites で見ていましたが、具体的にどのように攻撃するのかさっぱりイメージできず、あのグループだからまた超絶変態な手法だろうが、まぁそれほど深刻じゃないだろうと見込んでいました。 今回
無料でSSL使える時代きてた！CloudFlare最高！！！（？） - uzullaがブログ
しょうもない日記 YAPC行脚、福岡編 - uzullaがブログ とかかいた後になんとなくツイッターをみていたら、あるツイートをみまして。 packagist.jpをcloudflare対応したら、自動的にHTTPS対応できたでござる。すごい。一円も払ってないのに https://t.co/moCiiSwb44— Hiraku (@Hiraku) 2015年2月24日 それでCloudFlare(http://cloudflare.com/)がタダでSSL証明書を用意してくれるようになっていたのを知りました。 Cloudflare Free SSL/TLS | Get SSL Certificates | Cloudflare タダ！なんと甘美な響き！ オチ SNIでかまわないなら、CloudFlareをつかえばValidなSSLがタダで利用できる。 SNIとは？ NameBaseのVir
細かすぎて伝わらないSSL/TLS
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 「細かいと言うより長いよね」 はじめに こんにちは。ATS の脆弱性を発見した小柴さんや ATS に HTTP/2 の実装を行っている大久保さんと同じチームの一年目、匿名社員M さんからいじられている新人です。今回ありがたい事に、こういったすごい方々を含めモヒカン諸先輩方より「何か書かないの？」「いつ書くの？」という数々のプレッシャーお言葉をいただきました。 というわけで、SSL/TLS の Session 再開機能に関して書いていこうかと思います。 SSL/TLS は機密性、完全性そして真正性に対して安全な通信を行うための仕組みです。しかし、この仕組みは暗号技術を多用し特に接続において複雑なプロトコルを用い、Client, Se
なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
SSL入門
2005/10/02更新 高木浩光＠自宅の日記を拝見するにつけ、PKI としての SSL が 中途半端な理解により台無しにされている場面が多いように思えます。そこで（セキュリティの専門家ではないものの）私が理解している範囲で自分なりに入門解説を書いてみました。 ちなみに、SSL v3 に少しの改良を加えたものが TLS v1.0 ですが、技術的な細かい点を気にしない 場合は、SSLと総称されています。 ここでも、そんな細かいことは気にしていないので SSL と総称しています。 SSLしくみ解説 まず、SSLを理解するために必要な用語を解説し、次に SSLが PKI としてどのような構成要素で安全な通信路を形成しているか解説します。 暗号化と復号化 コンピューターで暗号化というと、暗号化する前のデータ （以下、「平文（ひらぶん）」と呼びます）と鍵となるデータ（以下「鍵」と呼びます） を使って
yebo blog: TLS 1.0に深刻な弱点が見付かる
2011/09/20 TLS 1.0に深刻な弱点が見付かる セキュリティ研究者のThai Duong氏とJuliano Rizzo氏は、TLS 1.0/SSL 3.0を使っているウェブサイトで、攻撃者にエンドユーザとウェブサイト間に流れるデータを気付かれずに復号化できるという深刻な弱点を発表するそうだ。今のところ、TLS 1.1や1.2は影響はないとのこと。今週、ブエノスアイレスで開催されるekopartyセキュリティ会議で、両氏はBEAST (Browser Exploit Against SSL/TLS)と呼ばれるコードでそのデモを行うそうだ(デモは23日)。Duong氏は、デモではPayPalアカウントにアクセスするために使われる認証用のcookieを復号化すると語っている。このBEASTは、標的となるブラウザにBEASTのクライアント側のJavaScriptコードを埋め込み、中間(
高木浩光＠自宅の日記 - 共用SSLサーバの危険性が理解されていない
■ 共用SSLサーバの危険性が理解されていない さくらインターネットの公式FAQに次の記述があるのに気づいた。 [000735]共有SSLの利用を考えていますが、注意すべき事項はありますか？, さくらインターネット よくある質問（FAQ）, 2010年2月10日更新（初出日不明） Cookieは、パスなどを指定することができるため、初期ドメイン以外では共有SSLを利用している場合にCookieのパスを正しく指定しないと、同じサーバの他ユーザに盗まれる可能性があります。 （略） 上記については、「同サーバを利用しているユーザだけがCookieをのぞき見ることができる」というごく限定的な影響を示していています。また、Cookieの取扱いについて、問い合わせフォームやショッピングカート等、ビジネス向けのウェブコンテンツを設置されていなければ特に大きな問題とはなりませんが、個人情報を取り扱われる管
最近ありがちなHTTPSの罠 | 水無月ばけらのえび日記
公開: 2011年8月14日0時50分頃 こんな話が……「SSL サイトの大半に脆弱性が存在 (japan.internet.com)」。 Ristic 氏によると、Web アプリケーション レベルでは、不適切な実行によって SSL のセキュリティを無効にするものは数多く存在するという。今回の研究で、Ristic 氏は世界の人気の高い SSL セキュアサイト30万件を分析し、SSL に関連する脆弱性の有無を調べた。その結果、保護されていないクッキーを使用したり、保護されたトラフィックと保護されていないトラフィックを混在させたりといった脆弱性が複数見つかったという。 Cookieのsecure属性なしとか、HTTPSとHTTPが混在しているといった話のようで。いずれも、HTTPSを無意味にする Cookieの話は、日本では2003年から警告されている定番の話ですね。 経路のセキュリティと同時
qmail はオワコン - どさにっき
2011年2月1日(火) ■ ちょっとトイレットペーパー買い占めてくる _ 一般向けの記事も出てるぐらいなんで別にいまさら書く必要もない気がせんでもないが、自分が後で思い出したくなったときのためにメモ。 _ ipv4 がめでたく売り切れました。厳密にはまだ /8 が5個残ってるけど、これは RIR に自動的に分配される分なので、おばちゃんおかわり、と言ってもごめんねーごはんもうないんだわ、となる。 _ 最後のおかわりは、大方の予想どおり APNIC に2ブロック。この APNIC の在庫も年内には枯渇するはず。ほとんど中国が使っちゃうのかなー。 _ 2003年8月の記事。 RIR exhaustion of the unallocated address pool would occur in 2022. 2003年の時点で、RIR の枯渇が2022年の予想。文中では言及されてないけど、
SSL 接続における証明書関連のお問い合わせについて - Japan IE Support Team Blog - Site Home - TechNet Blogs
If you were looking for MSDN or TechNet blogs, please know that MSDN and TechNet blog sites have been retired, and blog content has been migrated and archived here. How to use this site Archived blogs are grouped alphabetically by the initial letter of the blog name. Select the initial letter from the TOC to see the full list of the blogs. You can also type the name of the blog or the title of the
高木浩光＠自宅の日記 - 「VeriSignシール」という幻想
■ 「VeriSignシール」という幻想 オレオレ証明書ではないSSLサーバ証明書は、2つの独立した機能を果たしていると言える。1つ目は、SSLプロトコルによるサーバとクライアント間の暗号化通信のために不可欠な役割であり、2つ目は当該サイト運営者の実在証明の機能である。ただし、今日では、後者を含まない、前者だけのサーバ証明書もある。 後者の実在証明は、かつては認証局サービスを提供する各事業者がそれぞれの独自の基準で、サイト運営者の実在性を確認、認証していたが、それでは利用者にわかりにくいことから、認証の際の実在性確認の方法が標準化され、誕生したのがEV SSLであった。 その結果、VeriSignなど、古くから実在証明に力を入れていた認証局サービスでは、EVのものとEVでない実在証明付きサーバ証明書の2種類が存在することとなった。VeriSignでは、EV証明書の提供開始後も、EVでない実
HTTPSコネクションの最初の数ミリ秒
ほとんどの人がHTTPSとSSL (Secure Sockets Layer) を結びつけて考えます。SSLは1990年代半ばにNetscape社が開発した仕組みですが、今ではこの事実はあまり正確でないかもしれません。Netscape社が市場のシェアを失うにしたがって、SSLのメンテナンスはインターネット技術タスクフォース(IETF)へ移管されました。Netscape社から移管されて以降の初めてバージョンはTransport Layer Security (TLS)1.0と名付けられ、1999年1月にリリースされました。TLSが使われだして10年も経っているので、純粋な"SSL"のトラフィックを見ることはほとんどありません。 Client Hello TLSはすべてのトラフィックを異なるタイプの"レコード"で包みます。ブラウザが出す先頭のバイト値は16進数表記で0x16 = 22。 これは
yebo blog: OpenSSL 0.9.8mがリリース
2010/02/27 OpenSSL 0.9.8mがリリース OpenSSL 0.9.8mがリリースされた。再ネゴシエーションの欠陥を補うTLSの拡張RFC 5756を正式に実装している。 投稿者 zubora 投稿時間 18:57 ラベル: Open Source, Security, Web 1 コメント: c-yan さんのコメント... s/5756/5746/ 27/2/10 19:33 コメントを投稿
TLS/SSL脆弱性、プロトコルの改訂見通し | エンタープライズ | マイコミジャーナル
The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications. 2009年11月に入ってから、さまざまなメディアでTLS/SSLに介入者攻撃を可能にする脆弱性があるのではないかというニュースが報じられるようになった。TLS RFC 5246とそれ以前およびSSLv3とそれ以前のバージョンにリジェネレーションに関して介入者攻撃が実施できる深刻な問題があり、同脆弱性を利用されると通信経路の介入者がプロトコルストリームのはじまりの段階で任意の量のプレインテキストを挿入することが可能になり、さまざまな悪意ある操作できる可能性があるというもの。 この脆弱性が注目されたのは、実装上の問題ではなくプロトコルの設計上の欠陥であり、実装側
yebo blog: SSLプロトコルのRenegotiation問題が修正
2010/01/09 SSLプロトコルのRenegotiation問題が修正 SSL/TLSには Renegotiation (再ネゴシエーション) に関する深刻な問題を抱えていたが、最終ドラフトが承認され、この度 TLS プロトコル v1.2の仕様がRFC 5246として発行された。RFC 5246の発行で、RFC 3268、RFC 4346、RFC 4366が廃止され、RFC 4492 を更新したものとなる。仕様は完成したが、SSLライブラリやアプリケーションへの実装の更新に関してはこれからとなる。PhoneFactorがSSLの修正に関する情報を掲載しており、OpenSSLは0.9.8mで修正される予定。 Register | Fix finalized for SSL protocol hole 投稿者 zubora 投稿時間 10:06 ラベル: Protocol, Securi
HTTPS脆弱性、100のうち24は対処 | エンタープライズ | マイコミジャーナル
The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications. 2009年11月に入ってからTLS/SSLに介入者攻撃を可能にする脆弱性(CVE-2009-3555)があるというニュースが伝えられた。 この脆弱性を利用されると介入者がプロトコルストリームのはじまりの段階で任意の量のプレインテキストを挿入することが可能になる。HTTPとの組み合わせで調査されているが、ほかのプロトコルとの組み合わせでも同様の問題が発生する可能性があり、しかもこの脆弱性は実装側では抜本的な対処が難しい。OpenSSLは同脆弱性の原因となる処理をそもそも無効にするバージョンをOpenSSL 0.9.8lとして公開している。 TLS/SSLに設計
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News
SSL証明書は安全なのか？～Comodo/DigiNotar事件を振り返って ベリサインが最新動向など解説
【】IE使うならVista以降が無難、SSLの暗号強度調査結果から 