Google Chrome EV表示の終焉 - ぼちぼち日記
1. Chrome でEV証明書の組織名表示がなくなる ついにGoogleからChromeのURLバーからEV表示を削除する正式なアナウンスが出ました。 Upcoming Change to Chrome's Identity Indicators EV UI Moving to Page Info 現在(2019年8月) StableのChrome76では、以下の様にURLバー左側にEV証明書を利用していることを示す「組織名+国名」表示が付いています。 Chrome76のEV表示 2019年9月10日Stableリリース予定のChrome77からはEV表示がURLバーから削除され、鍵アイコンをクリックして表示されるPage Infoに「組織名＋国名」が表示されるようになります。 Googleのアナウンスでは、 "on certain websites" と書いてあることから一気にではなく
Let's encryptとSSL/TLSに関する誤謬 - Chienomi
全く以て意味不明な誤謬がはびこっていた上に、やたら上から目線だったので、消火しておこうと思う。 そもそもSSL, TLSとは何か SSL/TLSは暗号化技術である。 SSL/TLSのデータ通信自体は対称暗号である。ただし、暗号化に利用する暗号鍵は使い捨てる。 Cipherはかなり色々使えるのだけど、だいたいはTriple DES (3DES)かAESが使われる。 その手順は <- HelloRequest -> ClientHello <- ServerHello <- ServerCertificate <- ServerKeyExchange <- ServerHelloDone -> ClientKeyExchange -> Finished -> ChangeCipherSpec <- Finished <- ChangeChiperSpec <-> Application Dat
WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
Heart Bleedを読んだ - The first cry of Atom
int dtls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0], *pl; unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ heartbeatという機能の詳しいことは調べられていないけれどどうやらクライアントーサーバ型の機能を提供するものらしい。 つまり何らかのリクエストを受け取ってレスポンスを返すようなサービスを提供するものらしい。dtls1_process_heartbeatで大事なのは ポインタpだ。これはリクエストデータを受け取って格納している。このリクエストデータは構造体になっていて、以下のように記述されている。 typedef struct
Y!J API が止まった日 - GlobalSign の Root 証明書切れから学んだこと - OAuth.jp
昨日あたりから、Yahoo! Wallet や YConnect といった、Yahoo! Japan の API にアクセスできなくなったって人、ちらほらいるかもしれませんね。 僕もちょっとそういうケース見かけました。 なんか Yahoo! Japan がポカしちゃったの？とか、まぁ昨日まで健康に動いてたシステムが突然 Yahoo! Japan の API にアクセスできなくなっちゃったんだし、そらそう思うのもムリはない。 が、今回のケース、Yahoo! は全く悪くない！ プライバシーフリークはどうかと思うがな！！ では早速、今回起こったことを、振り返ってみましょう。 Yahoo! API にアクセスできなくなった Yahoo! Japan は、yahoo.co.jp 以外にも、CDN 用や API 用など、用途ごとにいくつかのドメインを持ってます。 今回止まったのは、その中の API 用
SSL/TLSライブラリの正しい使い方（もしくは、コモンネームの検証について）
スマホアプリの市場拡大に伴い、直接SSL/TLSライブラリを使用するプログラムを書く機会も増えてきている今日この頃かと思います。 SSL/TLSライブラリを使う際には、接続確立時にサーバの認証を正しく行う必要があります。具体的には、クライアントプログラムで以下の２種類の検証を行うことになります。 SSL/TLSライブラリがサーバの証明書の検証に成功したこと サーバの証明書に含まれるコモンネーム注1が接続しようとしたサーバと同一であること 前者については、OpenSSLの場合はSSL_CTX_set_verifyの引数にSSL_VERIFY_PEERを指定するなどして、ライブラリ側で処理を行わせることが可能です（証明書の検証に失敗した場合はSSL_connectがエラーを返します）。 一方、後者についてはSSL/TLSライブラリによって差があり、検証機能を有効にするために特別な呼出が必要だっ
技術/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 and Public Key Pinning | グローバルサインブログ
Chromeではgoogle.comに発行する正規な認証局をPinningしています。たとえ、信頼されたルート証明機関ストアに含まれた認証局からgoogle.comの証明書が発行されたとしても、Pinning のリストにない場合は警告表示が行われます。ほとんどの人はこの件が起きるまで、この技術がChromeに実装されていることを知りませんでした。 この件がきっかけでPinningの有効性は十分に認知され、Pinningをアプリケーション側に実装することでCA側による危殆化による不正な発行、または誤発行によるトラブルの拡大を防げることは実証されました。今後はPinningのリストを拡大していくことが課題かと思いますが、IETFのドラフトにおいても拡大には問題があると提示されています。 今後の動き Pinningをユーザーエージェント提供側にてハードコード化し、展開していくには慎重な対応が要求
Lavabit 事件とその余波、そして Forward Secrecy - セキュリティは楽しいかね？ Part 2
Lavabit事件 Lavabitという名前をみなさんご存知だろうか。NSAの監視活動について内部リークを行った Edward Snowden氏が利用していたメールサービスとして今年の夏に一躍有名になったところだ。Snowden氏は香港に滞在して複数のジャーナリストにNSAの内部情報を提供したあと、現在はロシアに一時亡命しているが、亡命が認められる前にモスクワ空港にしばらく滞在していたことがある。7月12日に空港内でプレスカンファレンスを行ったのだが、その時複数の人権団体に送った招待状が “edsnowden@lavabit.com” というメールアドレスからだった。この事が報道されると、「あの」Snowden氏が使っているメールサービスということで、利用希望者が殺到したらしい。(それまで新規登録は 200人/日だったのが、4,000人/日と20倍になった。) しかしそんな表の騒動の影で、
プレスリリース | SSLの脆弱性を検証するシステム「XPIA」を開発 | NICT-情報通信研究機構
インターネット上での安全な通信を支えるSSLで使われているRSA公開鍵の脆弱性を検証 脆弱なSSLサーバの分布状況を把握 インターネット上での安全な通信を支えるSSLの信頼性向上に寄与 独立行政法人 情報通信研究機構 （以下「NICT」、理事長：坂内 正夫） は、インターネット上での安全な通信を支えるSecure Socket Layer (以下「SSL」)の脆弱性を検証するシステムを構築しました。2012年、SSLに対する新しい脅威が報告され、世界中のSSLサーバの0.4%に当たる2万台以上が危険な状態にあることが明らかになりましたが、今般、NICTでは、SSLサーバの上記の脆弱性を検証するシステム「XPIA（エクスピア）」を開発し、現在危険な状態にあるSSLサーバの分布状況を把握することに成功しました。なお、本成果は、わが国の電子政府等において、暗号技術を安全に利用するための指針として
スノーデン事件の裏で起きていたSSL秘密鍵を巡る戦い:Geekなぺーじ
今月7日から9日にアリゾナ州で開催されたNANOG 59で、Ladar Levison氏がFBIにサービス全体のSSL秘密鍵を要求された話が公開されていました。 Ladar Levison氏が運営していた、Lavabitという電子メールサービスはスノーデン事件に関連して突如8月8日に閉鎖されています。 閉鎖時には詳細が書かれておらず、様々な憶測が語られていましたが、世界中から多数のネットワークエンジニアが集まるNANOGで、その一部始終が語られました。 この発表は、NANOG 59が開始される前の週に、裁判所が調査対象の氏名以外を機密解除したことによって実現しています。 インターネット上で提供されているサービス事業者にSSL秘密鍵を提出させ、かつ、その事実の公表が違法行為となるようにされてしまっている一方で、こういった内容を公的に語れるように裁判所で戦って、実際にそれを勝ち取るというのは凄
Hardening Your Web Server’s SSL Ciphers
There are many wordy articles on configuring your web server’s TLS ciphers. This is not one of them. Instead, I will share a configuration that scores a straight “A” on Qualys’s SSL Server Test in 2023. Disclaimer: I’m updating this post continually to represent what I consider the best practice at the moment – there are way too many dangerously outdated articles about TLS-deployment out there alr
高木浩光＠自宅の日記 - APOP終焉で「POP over オレオレSSL」の撲滅運動が可能に
■ APOP終焉で「POP over オレオレSSL」の撲滅運動が可能に APOP（エーポップ）方式におけるセキュリティ上の弱点（脆弱性）の注意喚起について, IPA, 2007年4月19日 回避方法は「『POP over SSL』や『ウェブメール』など、SSLによる暗号化通信を利用する」ことです。 というわけで、POP over SSLの特需が見込まれるところだが、MUAのサポート状況はどうだろうか。 大きなシェアを占めるBecky! はというと、POP over SSLをサポートしているのだが、残念なことに図1の設定がある。 この「証明書を検証しない」は、失効確認のことではない。オレオレ証明書の警告を出さない、そのチェックさえしないという設定だ。 これを設定した場合、偽サーバに接続*1しても何の警告もなしに処理される。（パスワードは偽サーバによって復号ないし解読され得る。） ここはデフ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Naked Security – Sophos News
http://japan.internet.com/webtech/20130207/2.html