SNIで1台のサーバ上に複数のSSLサイトを運用 – 前編 | さくらのナレッジ
ご無沙汰しております。細羽です。 昨年、AndroidにおけるSNI対応状況という記事で、SSL/TLSの拡張仕様であるSNI(Server Name Indication)について触れました。 少しニッチなテーマだと思っていましたが、つい先日、さくらのレンタルサーバでSNI SSLを提供開始というプレスリリースが発表されました。広いサービスでSSL/TLS導入への需要が高まっている今、このような事例は今後増えていくものと考えられます。 そこで本記事では、重要度が高まっているSNIについて、その技術の概要を改めて理解し、実際の運用に役立てられるように整理をしたいと思います。 知識の整理を目的にした前編と、実践を目的にした後編の2部構成でお届けします。 以下が前編の内容です。 SNIで何が出来るようになるのか SNIで複数ドメインが運用可能になるまで SNIが重要になりつつある背景 SSL運
理解してるつもりの 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
技術/Security/PKI,SSL,TLS/SSL, Certificate, Public Key Pinning - Glamenv-Septzen.net
ホーム 検索 - ログイン | | ヘルプ 技術/Security/PKI,SSL,TLS/SSL, Certificate, Public Key Pinning [ Prev ] [ Next ] [ 技術 ] 勉強中のメモ。（あくまでも個人の意見や見解です） Certificate and Public Key Pinning - OWASP https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning Certificate and Public Key Pinning | グローバルサインブログ｜SSLサーバ証明書ならグローバルサイン (旧日本ジオトラスト株式会社) https://jp.globalsign.com/blog/2013/certificate_public_key_pinning.html
Certificate, Key, and Trust Services | Apple Developer Documentation
Establish trust using certificates and cryptographic keys.
[改訂版] iPhoneアプリのSSL接続をパケットキャプチャする方法 | [ bROOM.LOG ! ]
はじめまして。この度このページの情報を参考にiPhoneでパケットキャプチャをやらせていただいたにゃんこと申します。 掲載されていた情報通りに進めると、何点か不明点があったので、役立つか？当たり前なのか？分かりませんが補足させていただきます。 ①まず使用するburpsuiteですが、バージョンによってインターフェイスが異なっています。 Ver1.1なら記載されている通り『[proxy]タブ – [option] → 「loopback only」がチェックされているのでこれを外します。』であっています。 Ver1.5（2013/5/12）では[proxy]タブ – [option] には、「loopback only」という項目がありません。 この場合は、みうさんのコメントにある通り（以下転記）になります。 >>Burp suiteでの設定ですが、Proxy→Optionsと辿り、Prox
![[改訂版] iPhoneアプリのSSL接続をパケットキャプチャする方法 | [ bROOM.LOG ! ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/aade9e21ce05ad2ed7895ccdfb10acc358475d21/height=288;version=1;width=512/https%3A%2F%2Fblog.rocaz.net%2Fuploads%2F2011%2F02%2FiPhoneApp_Capture2.png)
細かすぎて伝わらないSSL/TLS
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 「細かいと言うより長いよね」 はじめに こんにちは。ATS の脆弱性を発見した小柴さんや ATS に HTTP/2 の実装を行っている大久保さんと同じチームの一年目、匿名社員M さんからいじられている新人です。今回ありがたい事に、こういったすごい方々を含めモヒカン諸先輩方より「何か書かないの？」「いつ書くの？」という数々のプレッシャーお言葉をいただきました。 というわけで、SSL/TLS の Session 再開機能に関して書いていこうかと思います。 SSL/TLS は機密性、完全性そして真正性に対して安全な通信を行うための仕組みです。しかし、この仕組みは暗号技術を多用し特に接続において複雑なプロトコルを用い、Client, Se
OpenSSLライブラリを使ってプログラミング(1) - 再帰の反復blog
にわか知識 SSL……Secure Socket Layer。SSLv2はセキュリティ上の欠陥が複数見つかっているので使うべきではない。現在使われているのはSSLv3(SSL3.0)。 TLS……Transport Layer Security。IETFが標準化した規格。SSLという名前は意図的に避けたみたい。SSLとの互換性はない。現在のバージョンは1.0(だけどプロトコルバージョンの値は3.1)。 SSL/TLSでの「セッション」と「コネクション」 SSL/TLSには「セッション」と「コネクション」というふたつの用語がある。 コネクションは、TCPの接続に対応する。ソケット接続ひとつに対してひとつのコネクション。 クライアントとサーバの共有秘密情報(master_secretと呼ばれる)ひとつに対して、ひとつのセッションが対応する。 master_secretを共有するための計算コスト
不正なSSL証明書を見破るPublic Key Pinningを試す - ぼちぼち日記
先日のエントリー 「TLSとSPDYの間でGoogle Chromeがハマった脆弱性(CVE-2014-3166の解説)」で予告した通り、今回不正なSSL証明書を見破る Public Key Pinningの機能について解説します。 Public Key Pinning は2種類の方法があります。あらかじめブラウザーのソースコードに公開鍵情報を埋め込む Pre-loaded public key pinning と、サーバからHTTPヘッダでブラウザに公開鍵情報を通知するHTTP-based public key pinning (HPKP)の２つです。 Chromeは既に両者の機能を実装済ですが、ちょうど近日リリースされる Firefox 32 の Stable バージョンから Pre-loaded public key pinning が実装されました。Firefox32リリース記念と
第3回 SSL証明書ビギナー歓迎！ httpsから始まるURLの役割と仕組みを0から学ぼう | gihyo.jp
Webデザイナーなら知っておくべき サーバ知識相談室 第3回SSL証明書ビギナー歓迎！ httpsから始まるURLの役割と仕組みを0から学ぼう 昨年12月に話題になっていた、次のニュースを覚えていますか？ 痛いニュース(ﾉ∀`) : Firefoxでハローワークのサイトを開くと警告「安全性が確認できません」 - ライブドアブログ 要約すると、ハローワークのサイトをFirefoxで開くと「接続の安全性が確認できない」という警告画面が出て、サイトが表示されない事態になっていたというニュースです。さてここで「うわー、ハローワークいけてないな」と思われた方に質問です。このニュースが言っていることがきちんと分かりましたか？ 「ハローワークが何かやらかしたようだ」ということは分かると思います。そして、ニュース内で「証明書」という単語が何回か出てくるため、もしかしたらSSL証明書がらみで何か失敗した
SSL／TLS（Part.1）
まず、目立つのは下半分に横たわるReocord Protocolである。Record Protocolより上位にある各プロトコルは、Record Protocolを介して対向する通信相手とデータをやり取りする。Record Protocolは前述のように圧縮／暗号化を行っているので、これら上位プロトコルでの通信内容は原則として暗号化されることになる。 その際、Record Protocolでは、図中の「利用中の暗号化パラメータ」と書かれている情報に基づいて暗号化の処理を行っている。この「利用中の暗号化パラメータ」には、具体的に言えば、使用する圧縮アルゴリズムや暗号アルゴリズム、また暗号化／復号で使うキーなどが含まれる。いわば「圧縮／暗号化のルール」とでも考えれば分かりやすいだろう。 では、この「利用中の暗号化パラメータ」は、どうやって取り決めるのだろうか。「圧縮／暗号化のルール」である以上
自社サーバと交信するスマホアプリにおけるサーバ証明書の発行手法について（SSL Pinningと独自CA再考）
■背景 自社のサーバと通信する自社アプリについて、本来不要であるにも関わらず他社であるCAに認証情報の管理を委託することが多いわけですが、CAが証明書を誤発行した結果情報漏洩が発生したとして、その責任は自社にはないと主張できるのか、もう一度考えなおしたほうがいいんじゃないかと思うんです — Kazuho Oku (@kazuho) July 15, 2014 .@ockeghem @smbd @ando_Tw スマホアプリの提供においてはコードの署名鍵を安全に管理することが求められますが、その前提において通信相手の認証管理をCAに委託することにどれほどの意味があるんでしょう — Kazuho Oku (@kazuho) July 14, 2014 ■他社CAは信頼できるのか 特定のCAにpinningするのはしないより安全だけど、そもそも誤発行しないCAなんてあるのかという議論は重要。見知
SSL/TLSライブラリの正しい使い方（もしくは、コモンネームの検証について）
スマホアプリの市場拡大に伴い、直接SSL/TLSライブラリを使用するプログラムを書く機会も増えてきている今日この頃かと思います。 SSL/TLSライブラリを使う際には、接続確立時にサーバの認証を正しく行う必要があります。具体的には、クライアントプログラムで以下の２種類の検証を行うことになります。 SSL/TLSライブラリがサーバの証明書の検証に成功したこと サーバの証明書に含まれるコモンネーム注1が接続しようとしたサーバと同一であること 前者については、OpenSSLの場合はSSL_CTX_set_verifyの引数にSSL_VERIFY_PEERを指定するなどして、ライブラリ側で処理を行わせることが可能です（証明書の検証に失敗した場合はSSL_connectがエラーを返します）。 一方、後者についてはSSL/TLSライブラリによって差があり、検証機能を有効にするために特別な呼出が必要だっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSL/TLSの基礎と最新動向
Security with network protocols | App quality | Android Developers
httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita