オレオレ証明書をopensslで作る（詳細版） - ろば電子が詰まつてゐる
前回のopensslでRSA暗号と遊ぶでRSA暗号や秘密鍵について中身を色々といじってみた。続いて今回は、Apacheで使うオレオレ証明書を作ってみる。 細かいことはいいから、オレオレ証明書を作るコマンドだけ知りたい お急ぎの方は、以下3つだけやれば良い。これで10年間(3650日)有効なオレオレ証明書ができあがる。 $ openssl genrsa 2048 > server.key $ openssl req -new -key server.key > server.csr $ openssl x509 -days 3650 -req -signkey server.key < server.csr > server.crtできあがったserver.crtとserver.keyを、例えば/etc/httpd/conf/ 配下のssl.crt/ と ssl.key/ ディレクトリに設置
SSLとは？
SSLは「Secure Sockets Layer」の略でサーバー及びクライアント認証と暗号化通信を行うためのプロトコルです。 SSLというコトバを聞き慣れない方でも実は知らず知らずに使っているかもしれません。 SSLはその機能の通り暗号化を使った通信を行うときに威力を発揮します。 例えば、みなさんも１度は使ったことがあるであろうオンラインショッピングでは必ずと言っていいほどこのSSLを使用しています。 Internet ExplorerでSSL通信を行っていると、ウインドウの右下に以下のような鍵のマークが出てきますね。 通常インターネットを閲覧している時に流れているメッセージは暗号化されていないため、メッセージを第３者に盗聴されてしまう危険性があります。 とくにオンラインショッピングを行っている通信ではクレジットカードの番号など重要なメッセージがインターネットを流れおりこのままでは大変危
HTTP/2.0のALPN利用に伴うSSL負荷分散装置の不具合にご注意下さい - ぼちぼち日記
1. はじめに、 ただ今IETF-88@バンクーバーの開催が真っただ中です。スノーデン事件の余波もあり、インターネット技術（特にセキュリティ関連）の議論は熱くなっています。 ちょうど今朝未明（バンクバーでは11/5朝）に HTTP/2.0の標準化を進める httpbis ワーキンググループとセキュリティエリアの合同セッションが開催されました。合同セッションでは、ヘッダ圧縮技術(HPACK)のセキュリティや、HTTP接続(HTTPSではない）で通信の暗号化を行ったらどうか、といった興味深い議論が行われました。このうち将来HTTP/2.0の展開に重要な ALPN(Application Layer Protocol Negotiation) は、このミーティングで最終的な仕様を確定させる段階での議論でした。議論の中で、ALPNの導入によってブラウザから既存の実サービスへの接続に(少なからず)影
SSL/TLS
ポイント ●SSL（TLS）とは，主にWebアクセスでやり取りするデータを暗号化するための仕組みである。相手が信頼できるか確認する機能もある ●SSL（TLS）を利用してクライアントがサーバーを認証するためには，事前に認証局（CA）の公開鍵証明書を入手している必要がある ●ショッピング・サイトなどでSSLを利用する際に警告画面が出ないのは，あらかじめ認証局の公開鍵証明書がWebブラウザにインストールされているからである SSLは，第2章で勉強した技術の中では最も身近に感じると思いますが，いろいろな技術が組み合わさって出来ています。わからないところが出てきたら，すでに解説してきた記事へのリンクをたどって復習をしながら読み進めてみてください。 SSL/TLSとは SSL（Secure Sockets Layer）/TLS（Transport Layer Security）とは，主にクライアント
「OpenSSL」における Change Cipher Spec メッセージ処理の脆弱性対策について(JVN#61247051)：IPA 独立行政法人 情報処理推進機構
対象 サーバ側およびクライアント側で使用している「OpenSSL」のバージョンが以下の組み合わせの場合に、本脆弱性の影響を受けることが確認されています。 サーバ側: OpenSSL 1.0.1 系列のうち 1.0.1g およびそれ以前 クライアント側: OpenSSL 1.0.1 系列のうち 1.0.1g およびそれ以前 OpenSSL 1.0.0 系列のうち 1.0.0l およびそれ以前 OpenSSL 0.9.8 系列のうち 0.9.8y およびそれ以前 開発者が提供する情報をもとに最新版へアップデートしてください。 Q&A 通信経路上の攻撃者とは？ 本脆弱性を悪用するためには、クライアントとサーバの間に入って通信を中継する必要があります。このようなシナリオでの攻撃を一般に中間者攻撃といい、このときの攻撃者を本稿では通信経路上の攻撃者と呼んでいます。一般に、通信経路上の攻撃者となること
OpenSSLに再び脆弱性、MITM攻撃につながる恐れ
OpenSSLに再び脆弱性、MITM攻撃につながる恐れ：最初のリリースから16年間存在していた問題、修正版へのアップデートを推奨 オープンソースのSSL/TLS実装「OpenSSL」に、新たに複数の脆弱（ぜいじゃく）性が発見された。中にはMITM攻撃につながるおそれのある問題も含まれており、修正版0.9.8za／1.0.0m／1.0.1hへのアップグレードが呼び掛けられている。 オープンソースのSSL/TLS実装「OpenSSL」に、新たに複数の脆弱（ぜいじゃく）性が発見された。中にはMan-in-the-Middle（MITM）攻撃によって、暗号化通信の内容を第三者（＝攻撃者）が読み取ったり、改ざんしたりすることができる深刻な脆弱性も含まれている。 開発元のOpenSSLプロジェクトは米国時間の2014年6月5日、セキュリティアドバイザリを公開し、6つの問題を修正したバージョン0.9.8
Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について
■Heartbleedのリスクと善後策 Heartbleedは、攻撃者が一定の条件を満たすOpenSSLが動作しているサーバの、任意位置のメモリを外部から読み出すことができてしまうという脆弱性です。具体的には、以下のようなリスクが想定されています。 秘密鍵の漏洩による、偽サイトの出現（あるいは中間者攻撃） 秘密鍵の漏洩により、（過去のものを含む）パケットキャプチャの解読 サーバの同一プロセスが行った処理に関連する（他のユーザーのパスワードやセッションキーを含む）データの漏洩 漏洩した秘密鍵を用いた攻撃には、ユーザーを偽サイトへ誘導できたり、パケットの経由点を管理しているなどの、経路上の要件が必要になります。他のユーザーのデータの漏洩については、経路上の要件は不要な一方、攻撃の実施に近いタイミングでサーバにアクセスしたユーザーのデータしか漏れない、という違いがあります。 どこまで対策を施すべ
OpenSSLの脆弱性で想定されるリスク - めもおきば
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者（一般ユーザ）の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ
Heartbleed Bug
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private network
Webサイトを常時SSL化(https）する時に知っておきたいSEOチェックリスト
Webサイトを常時SSL化する、つまり全てのページをSSL暗号化してサイトへのアクセスを http://～から https://～に変更する時に、SEOの観点で注意したいポイント、実践したい事柄についてまとめます。 https:// でも問題なく検索エンジンに登録可能 かつて検索エンジンは、SSL通信のWebサイトをインデックスに登録することが苦手でした。たとえばGoogleは2000年代前半頃まで、https:// のウェブページを適切にクロールすることが困難でしたので、もしSSL暗号化しているページを検索結果に掲載したい場合は、http のページも用意する必要がありました。 しかし2013年12月現在、こうした制約はなくなり、https のサイトでも問題なく検索エンジンに登録することができます。 http と https サイトは別サイト扱い Googleは、内容が全く同一のサイトでも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita
https://www.ipa.go.jp/security/rfc/RFC2246-07JA.html
https://co-akuma.directorz.jp/blog/2013/07/ecc%E7%89%88ssl%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E4%BD%93%E9%A8%93%E8%A8%98%E3%81%9D%E3%81%AE1/
TLS/SSL 証明書のしくみ | DigiCert