【デジカルチーム ブログリレー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 [
こんにちは。クラウド基盤本部の野島です。 今年のインターンシップでは、プラットフォーム(自社基盤)コースとして2名の方を受け入れ、それぞれ異なる課題をやってもらいました。 そのうちの一つは Pingora に関する課題で、覚道さんに取り組んでいただきました。（もう一つの課題は nginx のキャッシュの性能に関するもので、これについては昨日の記事をご参照ください） Pingora は Cloudflare が開発したロードバランサのためのフレームワークであり、Rust を使って好きなロジックを組み込んだロードバランサを書くことができます。 今回のインターンでは Pingora を使って TLS のクライアント証明書を使った認証プロキシを作ってもらいました。 そこで、この開発の中で得られた Pingora や OpenSSL に関する知見を共有しようと思います。 この記事は覚道さんのインター
はじめに 2023年12月に「cURLの"--cacert"オプション利用時の挙動がmacOSとLinuxで異なる」という内容のissueが立ち、2024年3月にcURLの開発者であるDaniel Stenberg氏が「THE APPLE CURL SECURITY INCIDENT 12604」というタイトルで記事を公開しました。 この記事では本件に関する詳細の説明と検証、また独自の掘り下げを行い、macOS版cURLとオリジナルのcURLの違いについて解説します。ただし、本件は明らかになっていない部分が多くあるため、本記事には推測や仮説が含まれます。ご了承ください。 --cacertオプションにおけるmacOSのcURLとオリジナルのcURLの違い まずはDaniel Stenberg氏の記事で述べられた内容を元に、"--cacert"オプションにおけるmacOS版cURLとオリジナル
はじめに 本記事では、Red Hat製品、特にRHELとOpenShiftをFIPS準拠モードで使用するためにはどうするか、どのような仕組みによってFIPS準拠モードで稼働するか、について調べた内容を書きました。 KubernetesをFIPS準拠させるのはなかなか大変で、実際Red Hatも「OpenShiftはFIPSに対応していたつもりが実はできてませんでしたすみません」というCVEを発行したりしています (CVEの技術的背景等はこちらに解説があります)。 なお、本ドキュメントでは便宜上、FIPSの承認ステータスがFIPS validatedなものもModules in Progressなものもまとめて「RHEL(もしくはOpenShift)はFIPS準拠している」「FIPS準拠した暗号化モジュールを使って」のような表現をしていますのでご注意ください。正確にはざっくりRHEL 8系は
OpenSSL statement on the recent Intel/AMD Downfall/Inception vulnerabilities Aug 15, 2023 Last week marked the public announcement of the Downfall vulnerability in Intel CPUs and the Inception vulnerability in AMD CPUs. Both of these are microarchitectural side-channel attacks allowing an attacker with unprivileged execution on the same physical core as a victim process to extract confidential inf
開発していると、公開鍵暗号の技術を利用する場面は多々ある。 EC2インスタンスへのSSHする時や、Snowflakeの認証時に RSA キーペアの秘密鍵を利用する 公開鍵証明書 ... いろんな用語、トピックがあり混乱するのでまとめてみた。 ここではとりあえず特にRSA暗号を念頭に置き話を進める。 規格群 そもそも公開鍵暗号に関する技術はいろいろな形で規格が定められていたり、標準化されていたりする。 PKCS Public-Key Cryptography Standards の略で、RSAセキュリティというソフトウェア会社が考案した公開鍵暗号の規格群のこと。元々はRSAセキュリティ社が自社の暗号技術に関する特許を利用促進するために発行したのがはじまり。 近年ではその一部は IETF などと標準化が進められており、 RFC として整備されているものも多い。 内容ごとに PKCS #1 など
cybozu.com Cloud Platformチームのhsnとtomoです。今回はサイボウズで証明書更新の自動化を安全に行うための工夫をご紹介します。 背景 サイボウズではcybozu.comのサービスを提供するために数多くの証明書を取得し、管理しています。 今まではそれらをすべて手動で取得し、入れ替えを行っていました。 しかし、元来の運用ではいくつかの問題が浮上してきました。 手動更新の際は認証局によって更新手順が異なります。 具体的にはドメインの所有確認(DCV: Domain Control Validation)と証明書のダウンロード手順を、それぞれの認証局が独自に提供しています。 そのため、ドメインの更新手順書は複雑に長くなってしまいます。結果として更新の準備に時間がかかり、実施の際にミスも発生しやすくなっていました。 サイボウズでは証明書の有効期限が切れる1か月前に管理用の
C 言語 : HTTP サーバーとクライアントをつくるC 言語: libevent を使って HTTP クライアントをつくるC 言語: OpenSSL を使って HTTPS クライアントをつくるC 言語: OpenSSL を使って HTTPS サーバーをつくるC 言語: libevent を使って HTTPS サーバーをつくるC 言語: libuv を使って TCP echo サーバーをつくる Linux Socket Programming の著者が公開しているサンプルコード (ssl_server.c)をもとに書いた。 オンラインのドキュメントは10年ぐらい前のものが多く、サンプルコードで型の指定が不適切なものがあったりしてサンプルコードを探すのに苦労した。出版された教科書を読む必要がありそうだ。 OpenSSL の初期化でどの関数を呼び出せばよいのかで少し悩んだ。Wikibook と
これは、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
For compatibility with older Android devices, we'll be relying on a signature from an expired root, which is supported by Android. However, as Ryan Sleevi points out in “Path Building vs Path Verifying,” older versions of OpenSSL will reject a certificate chain that includes a signature by an expired root, even if OpenSSL could validate the chain by ignoring that certificate. Let’s Encrypt is not
HTTP Strict Transport Security (HSTS) HTTP Strict Transport Security (HSTS) is a mechanism for websites to instruct web browsers that the site should only be accessed over HTTPS. This mechanism works by sites sending a Strict-Transport-Security HTTP response header containing the site's policy. HSTS is supported by most major browsers. For more details on HSTS, see RFC 6797. Benefits of HSTS When
弊社では（既製の製品ではなく）独自開発したWebアプリスキャナを使用しており、品質や作業効率の向上のため、そのツールを毎年少しずつ改善させています（開発には主に筆者があたっています）。 本記事では、今年（2020年）の4～6月に開発した「XSSのトドメを刺す」機能について簡単に紹介します。 機能の概要 XSSの「トドメを刺す」というのは、ちゃんとJavaScriptが動作しそうな値を自動で生成して送り、それが本当に動きそうかを自動で確認することを指しています。 トドメ機能が実現する前は、記号等が含まれる値を送信し、それが反射する箇所の文脈（コンテキスト）の情報と、出力に施されるエンコードやフィルタの情報だけをもって脆弱性の有無を判断していました。例えば、通常の要素内容テキストにパラメータの値が反射するケースで言えば、基本的にツールが確認するのは「<」が反射するか否かまでで、実際に有意なタグ
御社の常時SSL (TLS) への対応はお済みですか。というわけで本稿ではRFCで標準化されているプロトコルのうち、SSL (TLS) に対応済みのものを列挙していきたいと思います。 用語の定義 本稿では、以下の用語を使います。 Implicit TLS （暗黙のTLS） TCPコネクション開始と同時にTLSセッションがいきなり始まる方式です。httpsなどはこれです。平文通信用と暗号通信用に別々のポートを割り当てる必要がありますが、そのぶん低レイテンシーを実現できます。 Explicit TLS （明示的TLS） TCPコネクションが確立すると、最初は平文で通信が始まり、そこからTLSへ移行する方式です。STARTTLSとか、そんな感じのコマンドが用意されているのがこれです。特徴としては、平文通信と暗号通信を同じポートでカバーできます。平文で始まって暗号へ切り替わるという手順を踏む分、レ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照くださ
1. はじめに つい先日のWindowsのセキュリティアップデートでWindowsのCryptoAPIの楕円曲線暗号処理に関連した脆弱性の修正が行われました。 「CVE-2020-0601 | Windows CryptoAPI Spoofing Vulnerability」 これがまぁ世界の暗号専門家を中心にセキュリティ業界を驚かせ、いろいろ騒がしています。 その驚きの一つは、この脆弱性の報告者がNSA(米国家安全保障局)だったことです。NSAはMicrosoftのアナウンスとは別により詳しい内容でこの脆弱性を警告するアナウンスを出しています。 「Patch Critical Cryptographic Vulnerability in Microsoft Windows Clients and Servers」 これまで数々の諜報活動をインターネット上で行ってきたNSAが、この脆弱性を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
