本ページの情報は2018年6月時点のものです。 独立行政法人情報処理推進機構(以下「IPA」という。)では、近年の情報セキュリティの基盤技術として広く利用されている暗号について、暗号技術評価プロジェクトCRYPTRECの活動を通じ、SSL (Secure Sockets Layer) / TLS (Transport Layer Security) の適切な利用促進を目的として、SSL/TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするための「SSL/TLS暗号設定ガイドライン」を2015年5月に公開しました。その公開から約3年が経過し、SSL/TLSを取り巻く状況の変化やSSL/TLSをサポートするアプリケーションのバージョンアップ等を反映した内容とするための改訂が必要となってきました。 また、2016年度のCRYPTREC活動において、暗号を正しく使う
全く以て意味不明な誤謬がはびこっていた上に、やたら上から目線だったので、消火しておこうと思う。 そもそもSSL, TLSとは何か SSL/TLSは暗号化技術である。 SSL/TLSのデータ通信自体は対称暗号である。ただし、暗号化に利用する暗号鍵は使い捨てる。 Cipherはかなり色々使えるのだけど、だいたいはTriple DES (3DES)かAESが使われる。 その手順は <- HelloRequest -> ClientHello <- ServerHello <- ServerCertificate <- ServerKeyExchange <- ServerHelloDone -> ClientKeyExchange -> Finished -> ChangeCipherSpec <- Finished <- ChangeChiperSpec <-> Application Dat
1. はじめに 昨日「SSL/TLS暗号設定ガイドライン 第2.0版」が公開されました。 前回から約3年経って今回はCRYPTREC暗号技術活用委員会で検討作業が行われたようです。 普段、TLS/HTTPSの記事を書いたり発表したりしている立場上、これを見逃すわけにはいけません。 本文冒頭では、 「本ガイドラインは、2018 年 3 月時点における、SSL/TLS 通信での安全性と可用性(相互接続性)のバランスを踏まえた SSL/TLS サーバの設定方法を示すものである。」 ということなので、できたてほっかほっかの最新ガイドラインを読ませていただきました。 読み進めてみるとChangelogが細かく書いてなく、以前のバージョンとどこがどう変わったのかよくわかりません。TLS1.3とかは絶対に新しく入った内容なんですが、細かいところはどうだろう… それでも全部(SSL-VPNを除く)をざっと
EngineeringSecurityWeak cryptographic standards removal noticeLast year we announced the deprecation of several weak cryptographic standards. Then we provided a status update toward the end of last year outlining some changes we'd made to make… Last year we announced the deprecation of several weak cryptographic standards. Then we provided a status update toward the end of last year outlining some
「良い本に出会った。感動した。」 by濱田 2014年4月のOpenSSLの脆弱性に起因するHeartbleed事件では、世界中のエンジニアが対応に追われました。この記事を読んでいる人で、あの日のことを懐かしく苦しく思い出す方、多いと思います。自分も例外ではないです。 それだけ広く使われていて、インターネット通信における基礎のSSLですが、皆さん、以下の点にすっきり答えられますか? SSLとTLSの違い SSLが保護するレイヤーは? SSHとの違いは? デジタル署名の「署名」の意味とは? 証明書は「誰」が「なに」を「どうやって」「証明」しているのか? 普段、EC2でキーペア発行したり、証明書導入したりしているエンジニアでも、案外、ここらへんがもやもやしている人も多いのではないでしょうか。 ぶっちゃけ、自分がそうでした。 そんな折に手に取ったこの本が、自分のニーズにばっちこーいでヒットしたの
文字でまとめると、RSA/DHEは鍵長が2倍になるごとに安全性が32ビットだけ増し、楕円曲線暗号は鍵長の半分のビット安全性を持ち、AESやChaCha20は効率的な解読アルゴリズムが見つかっていないので鍵長がそのままビット安全性になり、HMAC-SHAは現像攻撃耐性からダイジェスト長がそのままビット安全性になり、デジタル署名の証明書ハッシュは衝突攻撃耐性からダイジェスト長の半分がビット安全性になっています。 80ビット以下の暗号はすでに安全ではないとされており、SHA-1証明書もこれに含まれます。業界がSHA-2証明書への移行を急ぐわけですね。 112ビットも2031年以降は安全ではなくなるため新規利用不可の予定となっており、すでに推奨から外す動きが出ています。 128ビットは当面の間は安全であるとみなされており、署名・検証の計算量と安全性のバランスが最も良い方式になりそうです。 256ビ
少し前に、Logjam脆弱性が話題となりましたが、「ついでに」(という言い方も変かもしれませんが)DHEにまつわる他の問題も掘り出されてしまった感があり、ちょっとややこしいので整理しておきましょう。 まず、DHEとは DHEとは、盗聴の危険がある通信経路で安全に暗号鍵を共有するための方式です。RSA暗号と同様に1、離散対数の困難性(ある数gをx乗して、それを別な数pで割った余りは簡単に計算できるけど、gとpと余りがわかってもxは簡単に計算できない)ことを元にしています。 通信相手(アリスとボブ)の間で、$g$と$p$を共有します。 アリスとボブそれぞれがランダムに値($a$と$b$とします)を選びます。 それぞれが $g^a \bmod p=A$、$g^b \bmod p=B$ を求めて、相手に知らせます。 アリスとボブは、それぞれ相手からもらった値を自分の値だけ累乗して、余りを取ります。
以下は、Matt Mullenweg が書いた WordPress.org 公式ブログの記事、「Moving Toward SSL」を訳したものです。 誤字脱字誤訳などありましたらフォーラムまでお知らせください。 私たちは今、大きな岐路に立っています。2017年には、WordPress がホスト上で HTTPS を利用できるようにする機能を実装する年になるでしょう。よりスムーズなユーザーエクスペリエンスを実現するためには JavaScript が必要不可欠であることと同じく、パフォーマンスや SSL にはよりモダンな PHP バージョンは重要です。 SSL とは基本的に、ブラウザとサーバー間の接続が暗号化されていることを意味します。 SSL は以前は実装が難しく、高価だったり遅かったりすることがよくありました。モダンブラウザと、Let’s Encrypt のようなプロジェクトの驚くべき成功
HTTPS普及のために、無料でSSL/TLSサーバ証明書を発行しているサービス「Let's Encrypt」が、運営の支援を求めてクラウドファンディングでのキャンペーンを開始しています。 Make a More Secure Web with Let's Encrypt! by Sarah Gran | Generosity https://www.generosity.com/community-fundraising/make-a-more-secure-web-with-let-s-encrypt Launching Our Crowdfunding Campaign - Let's Encrypt - Free SSL/TLS Certificates https://letsencrypt.org/2016/11/01/launching-our-crowdfunding-cam
この記事は、2016 年 10 月 24 日付で Mozilla Security Blog に投稿された Distrusting New WoSign and StartCom Certificates(筆者: kwilson)の翻訳です。この翻訳は公式なものではありません。詳しくはこちらをご覧ください。 WoSign という認証局(CA)が技術面と運用面において多くの失態を犯していたこと、より深刻なことには、2016 年 1 月 1 日をもって SHA-1 SSL 証明書を発行できなくなる期限を回避するため、発行日を古い日時に改ざんして証明書の発行を行っていたことを Mozilla は確認しました。さらに、別の CA である StartCom の所有権を WoSign が完全に保有しているにも関わらず、Mozilla の要求するポリシーに反してこの事実を公開していなかったことも判明しま
Key features Clear output: you can tell easily whether anything is good or bad Ease of installation: Works for Linux, Mac OSX, FreeBSD, NetBSD and WSL/MSYS2/Cygwin out of the box: no need to install or configure something, no gems, CPAN, pip or the like. OpenBSD only needs bash to be postinstalled. Alternatively a Dockerfile is provided or you can just use docker run --rm -ti drwetter/testssl.sh F
SSL Server Testは便利だけど時間がかかる 各種サーバにおけるSSL/TLSの設定テストには、SSL Server Testがよく使われます。 各種ブラウザにおけるシミュレーション結果など、非常に詳しく出してくれる反面時間がかかります。 また、TCPの443番以外のテストには対応していないため、例えばメールサーバなどのテストを行うことができません。 そこでtestssl.sh testssl.shはシェルスクリプトベースのSSL/TLSのテストツールで、OpenSSL 1.0以降がインストールされているシステムで利用が可能です。 現時点(2015/01/28)の正式版である2.2では、以下の機能をサポートしました。 POODLE(CVE-2014-3566)に対するチェック HPKP(Public Key Pinning Extension for HTTP)への対応 OCSP
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 SSL/TLS CipherSuiteウォッチャーの@kjurです。 TechCrunch JPに昨日こんな記事が掲載されました。 Twitterが将来の暗号解読を防ぐため全サイトにわたってPerfect Forward Secrecyを採用 (2013年11月23日) http://jp.techcrunch.com/2013/11/23/20131122twitter-enables-perfect-forward-secrecy-across-sites-to-protect-user-data-against-future-decryption/ 最近、SSL/TLS のCipherSuiteについて、いろいろ趣味で調べているんですが
Version 1.6-draft (15 January 2020) SSL/TLS is a deceptively simple technology. It is easy to deploy, and it just works--except when it does not. The main problem is that encryption is not often easy to deploy correctly. To ensure that TLS provides the necessary security, system administrators and developers must put extra effort into properly configuring their servers and developing their applica
Published May 2015 Our study finds that the current real-world deployment of Diffie-Hellman is less secure than previously believed. This page explains how to properly deploy Diffie-Hellman on your server. We have three recommendations for correctly deploying Diffie-Hellman for TLS: Disable Export Cipher Suites. Even though modern browsers no longer support export suites, the FREAK and Logjam atta
Diffie-Hellman(DH)鍵交換の脆弱性を使ったTLSプロトコルに対する攻撃「Logjam Attack」に関する情報をまとめます。 脆弱性概要 脆弱性の概要情報は次の通り。 愛称 Logjam Attack (攻撃手法の愛称) Webサイト https://weakdh.org/ アイコン 無し CVE CVE-2015-1716(Microsoft) 発見者名 次の合同チームにより発見 フランス国立科学研究センター(CNRS) フランス国立情報学自動制御研究所(INRIA) Microsoft Research ジョンズホプキンス大学 ミシガン大学 ペンシルバニア大学 Logjam Attackの概要 Diffie-Hellman(DH)鍵交換の脆弱性。この脆弱性を用いて中間者攻撃が行われている環境において、TLS接続を512bitの輸出グレード暗号にダウングレードし、通信経
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
最新情報 関連ソフトウエアのサポート期間 OpenSSL 1.1.1系のサポート終了まであと、000日です。 (サポート終了予定日:2023年9月11日) OpenSSL 3.0.0系のサポート終了まであと、000日です。 (サポート終了予定日:2026年9月7日) サポートが終了したソフトウエア ACME v1のサービスが完全終了しました。(終了日:2021年6月1日)ACME v2に対応したACMEエージェントをご利用ください。 OpenSSL 1.1.0系のサポートが終了しました。 (サポート終了日:2019年9月11日) OpenSSL 1.1.1系へのアップグレードをお急ぎください。 OpenSSL 1.0.2系のサポート終了しました。 (サポート終了日:2019年12月31日) OpenSSL 1.1.1系へのアップグレードをお急ぎください。 OpenSSL 1.0.1系のサポ
The ordering of cipher suites in the Old configuration is very important, as it determines the priority with which algorithms are selected. OpenSSL will ignore cipher suites it doesn't understand, so always use the full set of cipher suites below, in their recommended order. The use of the Old configuration with modern versions of OpenSSL may require custom builds with support for deprecated ciphe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く