SSLの認証局とか証明書とか勉強し始めはホント難いよね このへんのSSL/TLSの仕組みって勉強し始めの頃は凄く難しく感じるのよね。分かりやすく解説してくれてるサイトってあんま見たこと無いし。 んで、 >>300,304 みたいなことは僕も昔考えたことあったわー、と懐かしみを覚えたのでレスってみた。 証明書を発行できるかどうかは証明書のフラグで決まっている、という >>303 の指摘も重要よね。 以下2chスレより引用 丁寧過ぎると評判のレスをしてるID:UyEJo1f2が僕なわけだがw 2chだとそのうち倉庫に行っちゃうかもしれないのでここにメモ。 【認証局】SSLに関するスレ 2枚目【ぼろ儲け】 http://hayabusa6.2ch.net/test/read.cgi/mysv/1286532904/298-309 298 :DNS未登録さん:2013/05/31(金) 13:31
数年前、Webは全体的に暗号化されていませんでした。HTTPSはWebページの最も重要な部分だけのために確保されていました。暗号化が必要なのは大切なユーザデータだけで、Webページの公開される部分は暗号化せずに送ってもいいということで意見が一致していました。 しかし、 今は 状況 が 違います 。現在では、どんなWebトラフィックでも暗号化されていないのは良くないということが分かっているので、Webサイトを運営する誰もがコンテンツに関係なく強固なHTTPSを設定しなければなりません。 お恥ずかしい話ですが、私自身のWebサイトは2年近くも全くHTTPSをサポートしていませんでした ^(1) 。 Eric Mill の 今すぐ無料でHTTPSに切り替えよう という素晴らしい記事が最終的に私に喝を入れてくれました。私は休暇中、HTTPSをセットアップして Qualys SSL Report で
Lenovo製のPCの一部にSuperfishというマルウェアが標準でインストールされていることが確認され、大きな問題となっています。 [2015-11-24追記] DELL製のPCにも、「eDellRoot」とされるSuperfishと同様の問題を持つルート証明書が導入されているようです。 DellのPCに不審なルート証明書、LenovoのSuperfishと同じ問題か - ITmedia エンタープライズ Dude, You Got Dell’d: Publishing Your Privates - Blog - Duo Security Joe Nord personal blog: New Dell computer comes with a eDellRoot trusted root certificate https://t.co/chURwV7eNE eDellRootで
(This is a write up of the talk that I gave at Velocity 2010 last Thursday. This is a joint work of myself, Nagendra Modadugu and Wan-Teh Chang.) The ‘S’ in HTTPS stands for ‘secure’ and the security is provided by SSL/TLS. SSL/TLS is a standard network protocol which is implemented in every browser and web server to provide confidentiality and integrity for HTTPS traffic. If there's one point tha
TLS has exactly one performance problem: it is not used widely enough. Everything else can be optimized. Data delivered over an unencrypted channel is insecure, untrustworthy, and trivially intercepted. We owe it to our users to protect the security, privacy, and integrity of their data — all data must be encrypted while in flight and at rest. Historically, concerns over performance have been the
OCSP Stapling: How CloudFlare Just Made SSL 30% Faster10/29/2012 CC BY-SA 3.0 image by Yathin sk This week CloudFlare is announcing several things we're doing to significantly improve the performance of SSL. Too few sites are secured with SSL. One of the reasons sites don't implement SSL is that it can slow down web performance. One of the less frequently discussed, but most significant, performan
2. 自己紹介 • 名前: 大津 繁樹 • 所属: 株式会社インターネットイニシアティブ(IIJ) アプリケーション開発部 • Twitter: @jovi0608 • ブログ: ぼちぼち日記 http://d.hatena.ne.jp/jovi0608/ • GitHub: https://github.com/shigeki/ • 新技術の検証・評価を行ってます。 (Node.js, SPDY, HTTP/2,HTML5) • iij-http2の開発を通じてIETFのHTTP/2標準化作業に参画中 • Node-v0.11.x へのパッチ提出はわずか。でもほとんどTLS関連です。 3. TLS (Transport Layer Security)の利用状況 TLS通信 認証、暗号化、 改ざん防止 図参照 https://plus.google.com/+IlyaGrigorik/po
Googleは、よくある設定ミスや既知のバグによってHTTPS接続の安全性が損なわれることを防ぐためのセキュリティテストツールをリリースした。「nogotofail」という、2014年に入って「Mac」と「iOS」に影響を与えた「goto fail」バグにちなんで名付けられたらしい同ツールは、インターネットに接続された端末やアプリケーションが、既知のバグや設定ミスといった、TLS(Transport Layer Security)やSSL(Secure Socket Layer)の暗号化の問題にさらされていないことを確認するための手段を提供する。 nogotofailのリリースに先立ち、TLS/SSLプロトコルには最近、複数の脆弱性が発見されていた。例えば、SSL 3.0で最近発見された「POODLE」や、OpenSSLの「Heartbleed」だ。どちらもサーバを深刻な攻撃にさらし、業界
1. はじめに、 先日、Chrome で 「Issue 401153002: Switch to BoringSSL. (Closed)」 という変更が行われました。これは、従来の Android向け Chrome では OpenSSL を利用していたのですが、今回これをGoogleがOpenSSLをforkしたBoringSSLに切り替えたことになります。 BoringSSLの発表からわずか1か月ぐらいですが、何回か Revert された末ようやく切り替えが成功したようです。 今回 BoringSSL を試しに少し使ってみましたので、そのレポートしてみたいと思います。 2. BoringSSLとは何か BoreingSSLがどういうもので、なぜOpenSSLをforkしたかは、GoogleのセキュリティExpert agl さんのブログ「ImperialViolet - BoringSS
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 もくじ 1. はじめに 2. SSLv3を無効化できる場合のサーバー対策 2.1. Apache HTTPD Server + mod_ssl 2.2. Apache HTTPD Server + mod_nss 2.3. nginx 2.4. lighttpd 2.5. Microsoft IIS 2.6. (訂正)Apache Tomcat (Java JSSE) 2.7. Node.js 2.8. IBM HTTP Server 2.9. Amazon Web Services 2.10. その他のサーバー 2.11. SSLv3 を無効化するリスク 2.12. OpenLDAP 3. 諸般の事情で SSLv3 を有効にせざるを得ない場
インターネットで買い物をするときに,クレジットカード番号や住所・氏名といった個人情報を送信することは多いだろう。こうした大事な情報を安心して送れるのは,SSL(secure sockets layer)というプロトコルのおかげだ。今回は,インターネットで暗号通信を実現するSSLを取り上げる。 イントロ:Webアクセスに欠かせない情報の秘密を守るしくみ Lesson1:アプリ同士のやりとりを暗号化,相手が信頼できるかも確かめる Lesson2:二つの暗号方式を組み合わせて,安全かつ高速に通信をする Lesson3:実際の通信はどうなってる?やりとりの詳細を見てみよう Lesson4:相手が信頼できることを確かめる「サーバー証明書」とは? 図解で学ぶネットワークの基礎:SSL編 修了テスト
Lesson4では,通信相手のサーバーが信頼できるかどうかを確認するしくみを見てみよう。ここでは,サーバーがクライアントに送信する「サーバー証明書」に注目する。 証明書には「署名」が付いている サーバー証明書は,サーバーの管理者が,「認証局」と呼ばれる組織に申請して発行してもらう(図4-1)。サーバー証明書には,サーバー運営者の組織名,認証局の組織名,証明書の有効期限,サーバーの公開鍵などの情報が書き込まれている。さらに,サーバー証明書には認証局の署名が付いている。署名とは,証明書の内容をハッシュした値を,認証局の秘密鍵で暗号化したデータである。 図4-1●「サーバー証明書」と「署名」とは? サーバー証明書は,サーバーの各種情報が書き込まれた情報で,サーバーの公開鍵が含まれている。サーバー証明書には,認証局の署名(証明書を認証局の秘密鍵で暗号化したデータ)が付いている。 [画像のクリックで
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
OpenSSLのheatbeatバグの対応のため、OpenBSDはOpenSSLのheatbeatを無効にするコミットをした。ただし・・・ src/lib/libssl/ssl/Makefile - view - 1.29 SegglemannのRFC520 heatbeatを無効化。 あのまともなプロトコルひとつ制定できないIETFの無能集団が、超重要なプロトコルで64Kの穴をこしらえるとか、マジであきれてものも言えねーわ。奴らはマジこの問題を本気で検証すべきだろ。なんでこんなことをしでかしたのか。こんな事態を承認した責任ある連中を全員、意思決定プロセスから取り除く必要がある。IETF、てめーは信用なんねぇ。 このコミットは、Makefileの中で、OpenSSLでheatbeatを無効にするマクロを定義するよう、コンパイラーオプションを指定するものだ。ただし、無効にするマクロは、OPE
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く