OpenSSLの「重大な」脆弱性を徹底解説 - Qiita
本記事は2022年11月4日（米国時間）に公開した弊社の英語ブログBreaking down the ‘critical’ OpenSSL vulnerabilityを日本語化した内容です。 なお、この脆弱性に関しては下記のブログもご参照ください。 2022年11月1日、OpenSSLチームは、深刻度 (Severity) が「高 (High)」の脆弱性2つ（CVE-2022-3602とCVE-2022-3786）の詳細を示すアドバイザリを公表しました。これは深刻度「クリティカル (Critical)」の脆弱性として予告されていましたが、実際のアドバイザリでは「高 (High)」に格下げされました。しかしながら、OpenSSLは主要な暗号化ライブラリの1つであり、インターネットのTLS暗号化通信の大部分を支えているため、これはまだ問題といえそうです。 この記事では、これら2つの脆弱性を特に
Old Let's Encrypt root certificate expiration and OpenSSL 1.0.2
Old Let's Encrypt root certificate expiration and OpenSSL 1.0.2 Sep 13, 2021 The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30. In some cases the OpenSSL 1.0.2 version will regard the certificates is
A Rust-based TLS library outperformed OpenSSL in almost every category
A tiny and relatively unknown TLS library written in Rust, an up-and-coming programming language, outperformed the industry-standard OpenSSL in almost every major category. The findings are the result of a recent four-part series of benchmarks [1, 2, 3, 4] carried out by Joseph Birr-Pixton, the developer behind the Rustls library. Benchmark resultsThe findings showed that Rustls was 10% faster whe
SSL証明書の内容をopensslで確認する - Qiita
発行されたSSL証明書の内容 サーバSSL証明書の購入をベンダに申し込み、めでたく発行されたらサーバに挿すわけだが、そもそもベンダに渡したCSRが手違いであったりして、万が一誤った内容の証明書が発行されていた場合、サーバに挿しても動かない（HTTPSアクセス不可、警告表示など）という悲惨な目に合ってしまう。 発行された内容が正しいかどうかをopensslコマンドで確認する方法があるので、是非覚えておきたい。 （正直コマンドをよく忘れてしまうので、このエントリはその備忘目的。） ハッシュ値の確認 秘密鍵、証明書、CSRの3つは全て同じハッシュ値が取れるようになっている。 これによりCSRをもとに作成された秘密鍵及び証明書が正しくできているかを確認することが出来る。 以下、それぞれのファイルのハッシュ値確認方法。 （ハッシュ値は適当） 秘密鍵のハッシュ確認 $ openssl rsa -noo
Intel CPUの脆弱性( Portsmash : CVE-2018-5407 ) - 脆弱性ブログ
OSSに関するセキュリティ・ツールの使い方・脆弱性等を紹介しています。 SELinux/Capability/AntiVirus/SCAP/SIEM/Threat Intelligence等。 OSS脆弱性ブログこちらでは主にOSSの脆弱性を取り上げていきます。11/02/2018にIntel CPUの脆弱性( Portsmash : CVE-2018-5407 )が公開されました。この脆弱性を利用してリサーチチームがOpenSSL(1.1.0h以下)のP-384秘密鍵をTLSサーバから盗み出すことが出来たということです。まだIntelのSAは出ていませんが、CVE-IDと情報、PoCが公開されてきましたので、今回はこの脆弱性の概要と、各ディストリビューションの対応について簡単にまとめてみます。 こんにちは。SIOS OSSエバンジェリスト/セキュリティ担当の面 和毅です。 こちらでは主に
openssl コマンドで Symantec の証明書を使っていないか効率よく調べる | はったりエンジニアの備忘録
Symantec が発行した SSL/TLS サーバ証明書が Chrome や Firefox で段階的にサポートされなくなります。もう間もなく最初の期限を迎えるので、改めて自分たちのサービスで使っていないか再チェックしました。 Google Developers Japan: Chrome が Symantec の証明書に対する信頼を破棄する予定について Distrust of Symantec TLS Certificates - Mozilla Security Blog Chrome 66 以降、Symantec によって 2016 年 6 月 1 日より前に発行された証明書に対する信頼が破棄されます。現時点では、Chrome 66 は Chrome ベータ版ユーザーに対して 2018 年 3 月 15 日に、安定版ユーザーに対して 2018 年 4 月 17 日頃にリリースされる
Speeding up TLS: enabling session reuse
Session reuse is one of the most important mechanisms to improve TLS performance: by submitting an appropriate blob to the server, a client can trigger an abbreviated handshake, improving latency and computation time. There exist two distinct ways to achieve session reuse: session identifiers as described in RFC 5246 and session tickets as depicted in RFC 5077. Update (2018-08) While the content o
The Most Common OpenSSL Commands
One of the most versatile SSL tools is OpenSSL which is an open source implementation of the SSL protocol. There are versions of OpenSSL for nearly every platform, including Windows, Linux, and Mac OS X. OpenSSL is commonly used to create the CSR and private key for many different platforms, including Apache. However, it also has hundreds of different functions that allow you to view the details o
Rustls and Servo
SimranGujral.github.io Rustls and Servo Background and Motivation Servo, Mozilla’s parallel browser engine, is written in Rust. Servo aims to create a browser which is memory safe and fast, the next generation browser.Before I get to what this post is about, I think it’s worthwhile to explain the jargon surrounding it, including the importance of TLS, what RusTLS is, and the effort to integrate Ru
OpenSSLの脆弱性(CVE-2017-3733)に見られる仕様とcastの落とし穴 - ぼちぼち日記
0. 短いまとめ OpenSSL-1.1.0dに脆弱性(CVE-2017-3733)が見つかり、Encrypt-Then-Mac と renegotiation を組み合わせて crashさせることができました。 この脆弱性は、仕様の準拠不足や不適切な変数の cast などが原因でした。 TLS1.3ではこういう落とし穴が少なくなるよう機能の根本的な見直しが行われています。 1. はじめに 先週 OpenSSL-1.1.0d に対してセキュリティアップデートがあり、 Encrypt-Then-Mac renegotiation crash (CVE-2017-3733)という脆弱性(Severity: High)が公開されました。 対象となった 1.1.0 は、昨年2016年8月にリリースされたOpenSSLの新しいリリースブランチです。1.1.0ではAPIの大幅変更もあり、まだあまり普及
OpenSSL update
OpenSSL update Rich Salz OpenSSL Update • All dev work is now done in public as GitHub pull requests • OpenSSL commits to next release as 1.1.1, which is API/ABI compatible • OpenSSL commits to TLS 1.3 as its next deliverable • Planning a specific delivery date with specific interop claims Progress so far (in the pipeline) • TLS 1.3 as a version understood – Supported_versions done – Underneath it
OpenSSLの脆弱性CVE-2016-800(DROWN)やCVE-2016-0702(CacheBleed)についてまとめてみた - piyolog
2016年3月1日(現地時間)、OpenSSL プロジェクトは脆弱性の愛称「DROWN」や「CacheBleed」を含む8件の脆弱性情報を公開し、これら影響を受けるものの修正を行った最新版をリリースしました。ここでは関連情報をまとめます。 脆弱性情報概要 注意喚起 OpenSSL の複数の脆弱性に関する注意喚起 - JPCERT/CC SSLv2 DROWN Attack - US-CERT OpenSSL Projectの公開情報 Forthcoming OpenSSL releases OpenSSL Security Advisory ［1st March 2016］ OpenSSL version 1.0.1s published OpenSSL version 1.0.2g published An OpenSSL User’s Guide to DROWN 2016年3月1日公
Name Constraints を使った独自CAの運用手順
ウェブブラウザが新機能をHTTPSでしか有効にしないことが多くなってきたので、開発環境でもHTTPSを使いたい。でも、開発環境用にサーバ証明書を買うのは手間。Let's Encryptも運用がめんどくさいとか、社内からしかアクセスできないサーバへの証明書発行が難しいとかいろいろあるし…ってそこでName Constraintsを使った独自CAですよ奥さん。 Name Constraints が何であるかについては、以前オレオレ認証局の適切な運用とName Constraintsに書いたとおり。 本稿では、Name Constraintsを使うCAの運用手順を説明する。 1. CA鍵と証明書の作成 1.1. CAの秘密鍵を作成 % openssl genrsa -out ca.key 2048 1.2. openssl.cnfにCA証明書に設定する属性を指定するセクションを追記 [priva
OpenSSLの脆弱性(CVE-2015-1793)によるAltチェーン証明書偽造の仕組み - ぼちぼち日記
TL;DR やっぱり書いていたら長文になってしまいました。あまりちゃんと推敲する気力がないので、変な文章になっているかもしれません。ご了承いただける方のみお読みください。 1. はじめに 昨晩未明にOpenSSL-1.0.2d, 1.0.1pがリリースされました。事前に予告されていた通り深刻度高の脆弱性CVE-2015-1793が修正されています。Advisoryを見ると、この脆弱性がiojs/Nodeに影響があるということが判明したので直ちにiojs/Nodeのアップデートを行い、今朝未明に無事脆弱性対応版をリリースしました。 今回が初めてではありませんが、深夜に日欧米のエンジニアがgithub上で互いに連携しながら速やかにセキュリティ対策のリリース作業を行うことは何回やってもなかなかしびれる経験です。時差もありなかなか体力的には辛いものがありますが、世界の超一流のエンジニアと共同でリア
OpenSSL #ccsinjection Vulnerability
[English] 最終更新日: Mon, 16 Jun 2014 18:21:23 +0900 CCS Injection Vulnerability 概要 OpenSSLのChangeCipherSpecメッセージの処理に欠陥が発見されました。 この脆弱性を悪用された場合、暗号通信の情報が漏えいする可能性があります。 サーバとクライアントの両方に影響があり、迅速な対応が求められます。 攻撃方法には充分な再現性があり、標的型攻撃等に利用される可能性は非常に高いと考えます。 対策 各ベンダから更新がリリースされると思われるので、それをインストールすることで対策できます。 （随時更新） Ubuntu Debian FreeBSD CentOS Red Hat 5 Red Hat 6 Amazon Linux AMI 原因 OpenSSLのChangeCipherSpecメッセージの処理に発見
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
OpenSSLにはこんなに問題が! LibreSSL開発者が発表 - BSDCan2014
The OpenBSD project produces a FREE, multi-platform 4.4BSD-based UNIX-like operating system. OpenBSDプロジェクトの開発者でありLibreSSLの開発に携わっているBob Beck氏は5月17日(カナダ時間)、「BSDCan2014: LibreSSL」においてLibreSSLの開発がはじまってからのおおよそ30日間のできごとを伝えた。なぜOpenSSLからLibreSSLを派生させ別プロジェクトとして取り組むことにしたのか、具体的にどういった変更を実施したのかなどが説明された。プロジェクトを立ち上げるきっかけはHeartbleed脆弱性が決め手だったのではなく、そのあとに取り組んだ作業によって別プロジェクトにするという判断が決定的なものになったと説明があった。懸念された点は特に次のとおり。
Heartbleed Bug
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private network
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OpenSSLの新たな脆弱性 CCS Injection が発見される
セキュリティ診断・検査のGMOサイバーセキュリティ byイエラエ
