Protecting data for the long term with forward secrecy
The latest news and insights from Google on security and safety on the Internet LogicMagic said... Are you planning on moving to TLS 1.1 or TLS 1.2? Are you planning on using an RC4 cipher that drops some packets to reduce the risk that the key can be recovered? Thank you for adding fast security which is transparent to users. November 22, 2011 at 3:22 PM agl said... TLS 1.1 and 1.2 support is a n
私が愛した openssl (SSL/TLS 編) - してみんとて
id:blooper:20120907 の続きですが、皆様におかれましては既に証明書が好きで好きでたまらなくなって、HTTPS を利用したサイトに行くと証明書の拡張まで読んだ後でなくては証明書の内容が気になってサイトの本文が読めなくなっているかと思いますが如何お過ごしでしょうか。 SSL は Secure Sockets Layer の頭文字で Netscape Communications が 1995 年に、ってのは wikipedia:Secure_Sockets_Layer でも見れば載ってるので見てね。で、RFC にしようってことで SSL は Netscape のでしょ? ってことで TLS (Transport Layer Security) に改名した、と記憶してるんだけど本当だっけな。ハンドシェイク時のレコードのバージョン見ると SSLv3.0 は 3.0 TLSv1.0
Qualys SSL Labs - Projects / SSL/TLS Deployment Best Practices
SSL/TLS is a deceptively simple technology. It is easy to deploy, and it just works . . . except that it does not, really. The first part is true—SSL is easy to deploy—but it turns out that it is not easy to deploy correctly. To ensure that SSL provides the necessary security, users must put more effort into properly configuring their servers. In 2009, we began our work on SSL Labs because we want
opensslでRSA暗号と遊ぶ - ろば電子が詰まつてゐる
opensslとRSA暗号についてちょっと調べてみようかな、と思った。 まずRSA暗号とは、 公開鍵暗号方式の実装のひとつである 2つの素数の積(ケタ数が大きい場合の素因数分解の困難さ)を利用している ってことを理屈としては理解しているけど、実際にopensslコマンドで作った鍵ファイルの中身がどうなっているのか? ということまで踏み込んだことが無かった。 というわけで、ちょっとその辺をコマンド叩きながら遊んでみることにする。 はじめに：opensslの操作について opensslコマンドは増築に増築を重ねすぎており、もはやそびえ立つ××のようである。ヤヴァいことになったレベルで機能てんこ盛りのコマンドなので、サブコマンドとして機能名を指定して使うことになる。 openssl command [ command_opts ] [ command_args ]上例の「command」には、R
ブラウザ、サーバーOSの保守状況について｜セコムのSSLサーバー証明書
※1 OpenSSL 1.0.1とそれより前の系列のOpenSSL Software Foundationによるサポートは、終了しました。 OpenSSL 1.0.2系列のOpenSSL Software Foundationによるサポートは、2019-12-31に終了しました。 OpenSSL 1.1.0系列のOpenSSL Software Foundationによるサポートは、2019-09-10に終了しました。 OpenSSL 1.1.1系列のOpenSSL Software Foundationによるサポートは、2023-09-11に終了しました。 OpenSSL 3.0系列のOpenSSL Software Foundationによるサポートは、2026-09-07までの予定です。 OpenSSL 3.1系列のOpenSSL Software Foundationによるサポート
ポストRSAを目指すECCとDSAを採用したSSLサーバー証明書
2月14日、日本ベリサインはECC、DSAという新しい公開鍵暗号アルゴリズムを用いたSSLサーバー証明書を発表した。従来、公開鍵暗号で用いられてきたRSAとは異なる選択肢を提供することで、保護とパフォーマンスを向上させるという。 RSA方式が危険な訳ではないが…… 従来、SSLサーバー証明書は、RSAのアルゴリズムをSSLのハンドシェイクに用いて、Webサーバーの運営団体の実在性を証明してきた。今回、日本ベリサインでは新たにECCとDSAという暗号アルゴリズムをサポートし、商用として初めて「マネージドPKI for SSL」のオプションとして提供するという。 発表会の冒頭、登壇した日本ベリサイン SSL製品本部 SSLプロダクトマーケティング部 上級部長 安達徹也氏は、まずシマンテックおよびベリサインとして、RSAの暗号方式が危ないと判断しているわけではないことを強調。米国や日本の政府機関
国際標準暗号GCMの新たな安全性評価結果(2012年08月17日)：プレスリリース | NEC
名古屋大学大学院工学研究科計算理工学専攻の岩田哲准教授、同専攻の大橋佳祐大学院生、日本電気株式会社の峯松一彦主任研究員のグループは、国際標準の認証暗号化方式であるGCM (注1) の安全性保証に欠陥があることを突き止めました。さらに、突き止めた欠陥を取り除き、GCMの安全性保証を修復することに成功しました。 GCMは高い計算効率を有しており、またその安全性が数学的に保証されていると考えられてきたことから多くの標準化プロセスで採用され、政府間・民間で広範に利用されています。しかし、その保証の理論的裏付けは無効であったことが明らかになりました。さらに、突き止めた欠陥を取り除き、GCMの仕様を変更することなくその安全性を数学的に保証することに成功しました。これにより、GCMの内部で用いるブロック暗号 (注2) が安全であれば、現実的な計算量の攻撃方法に対して、その成功確率はある限界値以上にはなら
Black Hat Europe 2013
Shelters or Windmills: The Struggle For Power and Information Advantage We are in the middle of a power shift in society that is at least as large as that of the printing press. Information advantage has always been the same as power: when the ruling elite has historically lost the information advantage, they have also lost power. Therefore, that advantage has always been defended, often with viol
Two new attacks on SSL decrypt authentication cookies
Two new attacks on SSL decrypt authentication cookies Aging standard isn't holding up very well in face of sophisticated attacks. Researchers have devised two new attacks on the Transport Layer Security and Secure Sockets Layer protocols, the widely used encryption schemes used to secure e-commerce transactions and other sensitive traffic on the Internet. The pair of exploits—one presented at the
What's New in SQL2016 CTP2 Release - MSDN Blogs
In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...
Strict-Transport-Security - HTTP | MDN
HTTP ガイド HTTP の概要 典型的な HTTP セッション HTTP メッセージ MIME タイプ（IANA メディア種別） HTTP の圧縮 HTTP キャッシュ HTTP 認証 HTTP Cookie の使用 HTTP のリダイレクト HTTP 条件付きリクエスト HTTP 範囲リクエスト コンテンツネゴシエーション HTTP/1.x のコネクション管理 HTTP の進化 プロトコルのアップグレードの仕組み プロキシサーバーとトンネリング HTTP クライアントヒント HTTP セキュリティ サイトの安全化 HTTP Observatory Permissions Policy コンテンツセキュリティポリシー (CSP) オリジン間リソース共有 (CORS) Cross-Origin Resource Policy (CORP) Strict-Transport-Securit
Lucky Thirteen Attackの攻撃手法を説明してみるよ - dec9ue's diary
Lucky ThirteenはTLS, DTLSのCBCモードを利用する暗号の脆弱性を突く攻撃です。具体的に言うと、CBCモードに対するPadding処理の弱い部分を狙ったPadding Oracle攻撃の一種です。 その影響とか、脅威とか、対処法とかは結構いろんな所で説明されているのですが、単純な興味とか、知識とか、内容を実感したい、というような方が読むことを想定した記事はあまりないように思われたので、その仕組みを説明したいと思います。 TLSパケットの仕組み まずはじめに、TLSパケットの暗号処理の仕組みを簡単に説明します。 イメージとしてはこんなかんじで、ヘッダ＋平文データのMAC(チェックサム的なもの)をとる→パディングをつける→暗号化する、 と言った流れでパケット(レコード)を構築します。 TLSのパディング ブロック暗号はそのままではブロックの幅に合わないデータを取り扱えないの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OpenSSL: CVS Web Interface
https://bugs.chromium.org/p/chromium/issues/detail?id=278370
Imperva Blog | Cyber Security Research, News & Insights
The BEAST summary - TLS, CBC, Countermeasures (Update 4)
Cryptographers Demonstrate New Crack For Common Web Encryption
#2635: 1/n-1 record splitting technique for CVE-2011-3389
duraconf/configs at master · ioerror/duraconf
http://japan.internet.com/webtech/20130214/2.html