【デジカルチーム ブログリレー6日目】デジカルチームの末永です。5月31日から開催される技術書典18で頒布するエムスリーテックブック8の、フルスクラッチして理解するSSL/TLSという章を担当しました。この章では、標準ライブラリ縛りでTLS 1.3のサーバーサイドを実装していきます。 techbookfest.org ここでは執筆の流れや小話などの裏側を書いていきます。 社内有志のメンバーによる新刊も頒布するようです 絶賛執筆中！以下のページからサークルをフォローして続報をお待ちください…！ #技術書典https://t.co/2W8FuGOJfM— エムスリー エンジニア公式 (@m3_engineering) 2025年5月13日 フルスクラッチして理解するSSL/TLS 執筆スケジュール いちばん大変だったポイント 実装・執筆小話 「長すぎる」問題 実際どれくらいAI使った？ フルス
Cybersecurity Newsは4月14日(現地時間)、「SSL Certificate Validity Reduced to 47 Days After Apple Proposal」において、SSL/TLS証明書の最大有効期間が47日に短縮されると報じた。 SSL/TLS証明書の最大有効期間は改訂を繰り返し徐々に短くなっている。現在の最大有効期間は398日だが、Appleが漏洩した場合の影響を軽減するためとして47日への短縮を提案(SC-081v3)し、関係機関およびコンシューマーの賛成多数で承認されたことがわかった。 SSL Certificate Validity Reduced to 47 Days After Apple Proposal 提案(SC-081v3)の概要と投票結果 Appleが提出した動議の内容や、投票の詳細は「Voting Period Begins:
[ ca ] default_ca = CA_default [ CA_default ] dir = ./ certs = $dir/certs crl_dir = $dir/crl database = $dir/index.txt new_certs_dir = $dir/newcerts serial = $dir/serial crlnumber = $dir/crlnumber crl = $dir/crl.pem RANDFILE = $dir/.rand name_opt = ca_default cert_opt = ca_default default_days = 365 default_crl_days= 30 default_bits = 2048 default_md = sha256 preserve = no policy = policy_match [
これは、Let's Encryptを支えるこの二人のルートCAと OpenSSLの物語である。 DST Root CA X3 (2000-2021) ISRG Root X1 (2015-2035) 〜2021年1月〜 ISRG Root X1「いままで一緒にやってきたDST Root CA X3さんの寿命が間近・・・このままだと僕を信頼してくれていないベテランの（具体的にいうと2016年くらいまでの）古いクライアントたちは Let's Encryptさんを信用してくれなくなっちゃう・・・どうしよう」 DST Root CA X3「どれ、わしが死ぬ前に(有効期限が切れる前に)お前が信頼に値する旨を一筆書いて残せばいいじゃろう。サラサラ」 Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3 Validity Not Bef
御社の常時SSL (TLS) への対応はお済みですか。というわけで本稿ではRFCで標準化されているプロトコルのうち、SSL (TLS) に対応済みのものを列挙していきたいと思います。 用語の定義 本稿では、以下の用語を使います。 Implicit TLS （暗黙のTLS） TCPコネクション開始と同時にTLSセッションがいきなり始まる方式です。httpsなどはこれです。平文通信用と暗号通信用に別々のポートを割り当てる必要がありますが、そのぶん低レイテンシーを実現できます。 Explicit TLS （明示的TLS） TCPコネクションが確立すると、最初は平文で通信が始まり、そこからTLSへ移行する方式です。STARTTLSとか、そんな感じのコマンドが用意されているのがこれです。特徴としては、平文通信と暗号通信を同じポートでカバーできます。平文で始まって暗号へ切り替わるという手順を踏む分、レ
1. はじめに 昨日「SSL/TLS暗号設定ガイドライン 第2.0版」が公開されました。 前回から約3年経って今回はCRYPTREC暗号技術活用委員会で検討作業が行われたようです。 普段、TLS/HTTPSの記事を書いたり発表したりしている立場上、これを見逃すわけにはいけません。 本文冒頭では、 「本ガイドラインは、2018 年 3 月時点における、SSL/TLS 通信での安全性と可用性（相互接続性）のバランスを踏まえた SSL/TLS サーバの設定方法を示すものである。」 ということなので、できたてほっかほっかの最新ガイドラインを読ませていただきました。 読み進めてみるとChangelogが細かく書いてなく、以前のバージョンとどこがどう変わったのかよくわかりません。TLS1.3とかは絶対に新しく入った内容なんですが、細かいところはどうだろう… それでも全部(SSL-VPNを除く)をざっと
Note: This is an outdated version of this blog post. This information is now maintained in a wiki page. See here for the latest version. The forthcoming OpenSSL 1.1.1 release will include support for TLSv1.3. The new release will be binary and API compatible with OpenSSL 1.1.0. In theory, if your application supports OpenSSL 1.1.0, then all you need to do to upgrade is to drop in the new version o
こちらは改訂前の旧版のページです。改題第2版の商品ページをご覧ください Webセキュリティ解説の決定版 "Bulletproof SSL and TLS" の全訳（原書2017年版へのアップグレード済み） Ivan Ristić 著、齋藤孝道 監訳 520ページ B5判 ISBN：978-4-908686-00-9 電子書籍の形式：PDF 2020年7月4日 第1版第5刷 発行（原書2017年版アップグレード対応済み） 本サイトにてユーザ登録のうえ購入いただくと、原著改訂第2版に収録されるTLS 1.3の解説章を付録として含んだ特別版PDFがお読みいただけます 現代生活を支えるネットワークにとって、通信の暗号化は不可欠の機能です。しかし、実際のインターネットで暗号化通信を利用できるようにするには、暗号化アルゴリズムの知識だけでなく、セキュリティプロトコルとその実装技術、さらに、基盤となる信
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 2017年前半に TLS 1.3 の仕様が発行されます。TLS 1.3 では仕様の簡略化が進められ、速度が改善されるとともにプライバシーの保護の強化が図られています。Google が提唱する次世代プロトコルの QUIC は TLS 1.3 に対応し、2018年に仕様が発行される予定です。curl の開発者は QUIC 対応を表明しています。 2016年にリリースされた OpenSSL v1.1.1 は TLS 1.3 に部分的に対応し、2017年にリリース予定の v1.1.1 で完全に対応します。 OpenSSL 1.1 系には
RSAの公開鍵暗号技術を利用するためには、鍵や証明書のファイルを扱う必要があるため、そのファイルフォーマットについて理解しておく必要があります。 実際、いろんな拡張子が登場するので、それぞれの意味を理解していないとすぐにわけがわからなくなります。そんなときのために備忘録をまとめてみました。 ファイルの拡張子の注意点 .DERと .PEMという拡張子は鍵の中身じゃなくて、エンコーディングを表している デジタル暗号化鍵やデジタル証明書はバイナリデータなのですが、MD5のハッシュ値のような単なる 値 ではなく、データ構造をもっています。.DERや .PEMはそのデータ構造をどういうフォーマットでエンコードしているかを表しています。そのため、.DERや.PEMという拡張子からそのファイルが何を表しているのかはわかりません。暗号化鍵の場合もあるし、証明書の場合もあります。 .DER 鍵や証明書をAS
Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN Cryptographic protocols like TLS, SSH, IPsec, and OpenVPN commonly use block cipher algorithms, such as AES, Triple-DES, and Blowfish, to encrypt data between clients and servers. To use such algorithms, the data is broken into fixed-length chunks, called blocks, and each block is encrypted separately according to a mode of opera
opensslコマンド関係の備忘録。 サーバに設定された証明書を確認する 正しくSSL通信が為されているならば証明書の署名と発行者、またSSLネゴシエーションのパラメータや暗号方式が得られる。 openssl s_client -connect HOSTNAME_OR_ADDR:443 -showcerts 中間証明書が正しく設定されているならばそれらを通じてルートCAまで一貫して辿れることが確認できる。 なお、ポート番号にはデフォルトでは以下を指定する。 443 HTTPS 995 POP over SSL 465 SMTP over SSL 993 IMAPS このコマンドは「---」で表示が止まるが、TCPセッションは接続したままになっている。HTTPSの場合はget /ENTERを打てばトップページの内容が得られるし、SMTPならHELO等を打つことでSMTPサーバと直接会話するこ
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.
昨年2014年は、SSL（Secure Sockets Layer）とTLS（Transport Layer Security）というプロトコルがリリースされてから20年が経過し、HeartBleedやPOODLEなどの脆弱性でも話題となった年でもありました。今回の10分講座では、SSL/TLS暗号通信プロトコルの動向を紹介します。 SSL/TLSとは SSL/TLSは最も普及している暗号通信プロトコルの一つで、TCP/IPの4レイヤーモデルのトランスポート層とアプリケーション層との間に位置するため、広く使われているHTTPばかりでなく、SMTPなど任意のプロトコルを安全に送受信する目的で使用することができます。特にWebにおいて暗号通信機能を提供できるようになったことにより、オンラインショッピング、オンラインバンキングやユーザー認証を必要とする各種オンラインサービスの普及に重要な役割を担
30分でわかるマイクロサービスアーキテクチャ 第2版 - Forkwell Library #17 https://forkwell.connpass.com/event/273812/ https://www.youtube.com/watch?v=xYTtw0ZgUNU オライリー・ジャパン > マイクロサービスアーキテクチャ 第2版 https://www.oreilly.co.jp/books/9784814400010/
前方秘匿性（forward secrecy）とは、以下のような性質を指します。 公開鍵暗号の秘密鍵のように、比較的長期に渡って使われる鍵が漏えいしたときでも、それまで通信していた暗号文が解読されないという性質 鍵が漏れることも想定せよ――クラウド時代における「楕円曲線暗号」の必然性 - @IT 鍵が攻撃者や諜報機関など第三者の知るところとなった場合でも、それまで通信していた暗号文が解読されないようにしないといけない、という考え方とともに、最近 HTTPS を利用するウェブサイトにおいても導入が求められるようになってきた概念です。 前方秘匿性を満たすウェブサイトの設定方法については、TLSの暗号化方式をECDH_RSAあるいはECDHE_RSAに設定すれば良い、と述べている文献が多いです。 ですが、ほとんどのウェブサーバにおいて、それは誤りです。 なぜか。 通信を暗号化する鍵（セッション鍵）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
