Lucky ThirteenはTLS, DTLSのCBCモードを利用する暗号の脆弱性を突く攻撃です。具体的に言うと、CBCモードに対するPadding処理の弱い部分を狙ったPadding Oracle攻撃の一種です。 その影響とか、脅威とか、対処法とかは結構いろんな所で説明されているのですが、単純な興味とか、知識とか、内容を実感したい、というような方が読むことを想定した記事はあまりないように思われたので、その仕組みを説明したいと思います。 TLSパケットの仕組み まずはじめに、TLSパケットの暗号処理の仕組みを簡単に説明します。 イメージとしてはこんなかんじで、ヘッダ＋平文データのMAC(チェックサム的なもの)をとる→パディングをつける→暗号化する、 と言った流れでパケット(レコード)を構築します。 TLSのパディング ブロック暗号はそのままではブロックの幅に合わないデータを取り扱えないの
GoogleやMicrosoftが、将来的にSHA-1を使用した署名の証明書を安全なものとして扱わないとするアナウンスは、記憶に新しいかと思います。 Google Online Security Blog: Gradually sunsetting SHA-1 Windows PKI blog: SHA1 Deprecation Policy このアナウンスを受けて認証局各社ともSHA-2への移行を薦めている。 さて、仮にクライアントがSHA-2に対応していない場合はどうなるのでしょうか？サーバは証明書を出し分けたり出来るのでしょうか？ （実装はともかくして）TLS1.2より、ハンドシェイク時にクライアントのサポートしてる署名アルゴリズムを伝えられるようです。 Signature Algorithms Signature Algorithms extension はRFC5246の7.4.
プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの / Streamlining Product Validation in Growth Phase
この記事は、インテル® ソフトウェア・ネットワークに掲載されている「Intel® AES-NI Performance Testing on Linux/Java Stack」(http://software.intel.com/en-us/articles/intel-aes-ni-performance-testing-on-linuxjava-stack/) の日本語参考訳です。 目次 1. 要旨 2. はじめに 2.1. 目標 2.2. インテル® AES-NI の機能 2.3. 目的 2.4. 対象者 2.5. 用語 2.6. 謝辞 3. システムのセットアップと設定 3.1. コンポーネント 3.2. テストシステムでインテル® AES-NI を有効/無効にする 3.3. ローカルホストからインテル® AES-NI ステータスを確認する 3.4. ソフトウェアのセットアップ 3
『Java って AES-NI 効いてるの？』って17歳女子高生の素朴な疑問から。 結果： 128KB のバイト配列を食わせた結果 AES-NI あり 663,478 ns AES-NI なし 1,880,994 ns 2.8 倍ぐらいはやい。 OpenSSLを使ったベンチ のことを思うと振るわないけど効果はあるのね。 環境 Java8 1.8.0u45 64bit java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) CPU Intel i7 4600U ARK | Intel® Core™ i7-4600U Processor (4M Cache, up to
Oracle has this to say about Java 8 with regards to AES-NI: Hardware intrinsics were added to use Advanced Encryption Standard (AES). The UseAES and UseAESIntrinsics flags are available to enable the hardware-based AES intrinsics for Intel hardware. The hardware must be 2010 or newer Westmere hardware. For example, to enable hardware AES, use the following flags: -XX:+UseAES -XX:+UseAESIntrinsics
Resources > Blog > HTTP Public Key Pinning: You're doing it wrong! HTTP Public Key Pinning (HPKP) is a security feature that can prevent fraudulently issued TLS certificates from being used to impersonate existing secure websites. Our previous article detailed how this technology works, and looked at some of the sites that have dared to use this powerful but risky feature. Notably, very few sites
ChaCha（チャチャ）という一見ふざけた名前の暗号が最近（自分の中で）話題ということで，勉強がてらに記事にしてみました． 背景 ChaChaの構造 Salsa20 Chacha 初期状態 ラウンド操作 ChaChaの安全性 実装してみた 参考 背景 2016年4月現在，TLSの新しいバージョンとしてTLS 1.3が提案されており，ドラフトが公開されている． draft-ietf-tls-tls13-11 - The Transport Layer Security (TLS) Protocol Version 1.3 TLS 1.2からの大きな変更点として，以下の2つがある． ハンドシェイクの省略によるRTT（Round Trip Time）の削減 危殆化した暗号の廃止 「危殆化した暗号」とは，Forward SecrecyでないCipher Suite（RSAのみを用いたもの）や，認証
HAProxy 1.5でALPNに対応していた。 HTTP/2 over TLSの通信を、HAProxyでTLSを終端することで、TLS対応を行わないであろうVarnishなどでもh2c接続が可能となる。 (HAProxy自体のhttp2対応はまだ先) 今回はバックエンドにNginxをh2cでリッスンさせて試してみた 構成 構成としては以下の図のとおりである。 HAproxyはTLSの終端のみを行い、中身のメッセージをそのままバックエンドに送信する。この時HAProxyはHTTP/2の処理は行わない。 バックエンドのNginxはh2cのダイレクトで通信を受け付ける。 HAProxyの設定 bindでalpn h2を指定する if { ssl_fc_alpn -i h2 }で、h2ならh2cのバックエンドへ、そうでなければhttp/1.1のバックエンドへ (opensslのバージョンが足りな
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog あっどうも、社員Mです。 細かすぎて伝わらないSSL/TLSというタイトルにて、1年目とはとても思えない1年目の新人さんによる TLS Session resumption の技術についてアツい紹介がありました。 私は、このあたりの技術を片っ端から人柱することを専門に担当しています。本日はその結果について簡単にご紹介できればと思います。 ※ 弊社で謎の人物キャラがはやるのは前CTOの明石さんの影響ということにしておきます（笑）。 はじめに スマートフォンが利用するモバイルネットワークは応答時間が大きくなる傾向があり、ユーザー体験を向上させていくためには、応答時間とパケットの往復回数に着目した技術的な工夫が必要だと感じております。
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
Chandan Kumar is a founder of Geekflare. He is a technology enthusiast and entrepreneur who loves to help businesses and people around the world. Chandan has worked at BNP Paribas, Citibank, Deutsche Bank, Motorola, and HP. He’s got an in-depth understanding of business software and resources. Verify your SSL, TLS & Ciphers implementation. SSL verification is necessary to ensure your certificate p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
