タグ

sslに関するdefiantのブックマーク (112)

  • CFSSL

  • 「SSL/TLS暗号設定ガイドライン改訂及び鍵管理ガイドライン作成のための調査・検討」報告書 | アーカイブ | IPA 独立行政法人 情報処理推進機構

    ページの情報は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暗号設定ガイドライン改訂及び鍵管理ガイドライン作成のための調査・検討」報告書 | アーカイブ | IPA 独立行政法人 情報処理推進機構
  • 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

    defiant
    defiant 2018/06/10
    主題は確かにそうだけど細かい表現が微妙。3DESはイマドキそんなに使われますか? SSLは目的の相手と暗号通信するのが重要なんて暗号化だけが重要なわけではなく署名も重要。改ざんされてないことも確認しないとね。
  • 「SSL/TLS暗号設定ガイドライン 第2.0版」を読んで - ぼちぼち日記

    1. はじめに 昨日「SSL/TLS暗号設定ガイドライン 第2.0版」が公開されました。 前回から約3年経って今回はCRYPTREC暗号技術活用委員会で検討作業が行われたようです。 普段、TLS/HTTPSの記事を書いたり発表したりしている立場上、これを見逃すわけにはいけません。 文冒頭では、 「ガイドラインは、2018 年 3 月時点における、SSL/TLS 通信での安全性と可用性(相互接続性)のバランスを踏まえた SSL/TLS サーバの設定方法を示すものである。」 ということなので、できたてほっかほっかの最新ガイドラインを読ませていただきました。 読み進めてみるとChangelogが細かく書いてなく、以前のバージョンとどこがどう変わったのかよくわかりません。TLS1.3とかは絶対に新しく入った内容なんですが、細かいところはどうだろう… それでも全部(SSL-VPNを除く)をざっと

    「SSL/TLS暗号設定ガイドライン 第2.0版」を読んで - ぼちぼち日記
  • Weak cryptographic standards removal notice

    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

    Weak cryptographic standards removal notice
  • SSLを基礎から学ぶには最適の入門書「食べる!SSL!- HTTPS環境構築から始めるSSL入門」 | DevelopersIO

    「良いに出会った。感動した。」 by濱田 2014年4月のOpenSSLの脆弱性に起因するHeartbleed事件では、世界中のエンジニアが対応に追われました。この記事を読んでいる人で、あの日のことを懐かしく苦しく思い出す方、多いと思います。自分も例外ではないです。 それだけ広く使われていて、インターネット通信における基礎のSSLですが、皆さん、以下の点にすっきり答えられますか? SSLとTLSの違い SSLが保護するレイヤーは? SSHとの違いは? デジタル署名の「署名」の意味とは? 証明書は「誰」が「なに」を「どうやって」「証明」しているのか? 普段、EC2でキーペア発行したり、証明書導入したりしているエンジニアでも、案外、ここらへんがもやもやしている人も多いのではないでしょうか。 ぶっちゃけ、自分がそうでした。 そんな折に手に取ったこのが、自分のニーズにばっちこーいでヒットしたの

    SSLを基礎から学ぶには最適の入門書「食べる!SSL!- HTTPS環境構築から始めるSSL入門」 | DevelopersIO
  • SSL/TLSの暗号スイートは何を基準に優先すべきか?(1) ~鍵長と安全性~ | BLOGRAM

    文字でまとめると、RSA/DHEは鍵長が2倍になるごとに安全性が32ビットだけ増し、楕円曲線暗号は鍵長の半分のビット安全性を持ち、AESやChaCha20は効率的な解読アルゴリズムが見つかっていないので鍵長がそのままビット安全性になり、HMAC-SHAは現像攻撃耐性からダイジェスト長がそのままビット安全性になり、デジタル署名の証明書ハッシュは衝突攻撃耐性からダイジェスト長の半分がビット安全性になっています。 80ビット以下の暗号はすでに安全ではないとされており、SHA-1証明書もこれに含まれます。業界がSHA-2証明書への移行を急ぐわけですね。 112ビットも2031年以降は安全ではなくなるため新規利用不可の予定となっており、すでに推奨から外す動きが出ています。 128ビットは当面の間は安全であるとみなされており、署名・検証の計算量と安全性のバランスが最も良い方式になりそうです。 256ビ

  • LogjamとDHEにまつわる問題 - Qiita

    少し前に、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$ を求めて、相手に知らせます。 アリスとボブは、それぞれ相手からもらった値を自分の値だけ累乗して、余りを取ります。

    LogjamとDHEにまつわる問題 - Qiita
  • SSL への移行

    以下は、Matt Mullenweg が書いた WordPress.org 公式ブログの記事、「Moving Toward SSL」を訳したものです。 誤字脱字誤訳などありましたらフォーラムまでお知らせください。 私たちは今、大きな岐路に立っています。2017年には、WordPressホスト上で HTTPS を利用できるようにする機能を実装する年になるでしょう。よりスムーズなユーザーエクスペリエンスを実現するためには JavaScript が必要不可欠であることと同じく、パフォーマンスや SSL にはよりモダンな PHP バージョンは重要です。 SSL とは基的に、ブラウザとサーバー間の接続が暗号化されていることを意味します。 SSL は以前は実装が難しく、高価だったり遅かったりすることがよくありました。モダンブラウザと、Let’s Encrypt のようなプロジェクトの驚くべき成功

    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

    無料でサーバ証明書を発行してくれる「Let’s Encrypt」が運営資金をクラウドファンディングで募集
  • 【翻訳】WoSign と StartCom による今後の証明書は拒否します - Mozilla Security Blog 日本語版

    この記事は、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 の要求するポリシーに反してこの事実を公開していなかったことも判明しま

    【翻訳】WoSign と StartCom による今後の証明書は拒否します - Mozilla Security Blog 日本語版
  • /bin/bash based SSL/TLS tester: testssl.sh

    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/TLSのテストが行えるtestssl.sh - Qiita

    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

    素早くSSL/TLSのテストが行えるtestssl.sh - Qiita
  • 自堕落な技術者の日記 : TwitterのPerfect Forward Secrecy(PFS)対応 - livedoor Blog(ブログ)

    は喰ってるか飲んでるかですが、よく趣味でカラオケ・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について、いろいろ趣味で調べているんですが

    自堕落な技術者の日記 : TwitterのPerfect Forward Secrecy(PFS)対応 - livedoor Blog(ブログ)
  • SSL and TLS Deployment Best Practices

    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

    SSL and TLS Deployment Best Practices
  • Logjam: PFS Deployment Guide

    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

  • Logjam Attackについてまとめてみた - piyolog

    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の輸出グレード暗号にダウングレードし、通信経

    Logjam Attackについてまとめてみた - piyolog
  • 理解してるつもりの 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

    理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 · けんごのお屋敷
  • Apache 2.4系でHTTP/2対応サーバを構築してみるテスト。

    最新情報 関連ソフトウエアのサポート期間 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系のサポ

    Apache 2.4系でHTTP/2対応サーバを構築してみるテスト。
  • Security/Server Side TLS - MozillaWiki

    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