mTLS: When certificate authentication is done wrong
EngineeringSecuritymTLS: When certificate authentication is done wrongIn this post, we'll deep dive into some interesting attacks on mTLS authentication. We'll have a look at implementation vulnerabilities and how developers can make their mTLS systems vulnerable to user impersonation, privilege escalation, and information leakages. Although X.509 certificates have been here for a while, they have
書評 プロフェッショナルTLS&PKI 改題第2版 (PR) - ぼちぼち日記
はじめに 『プロフェッショナルTLS&PKI改題第2版（原題: Bulletproof TLS and PKI Second Edition）』が出版されました。今回は出版前のレビューには参加していませんが、発売直後にラムダノートさんから献本をいただきました。ありがとうございます(そのためタイトルにPRを入れてます)。原著のサイトでは前バージョンとのDiffが公開されており、今回は翻訳の確認を兼ねて更新部分を重点的に読みました。このエントリーでは、改訂版のアップデート部分がどのようなもので、今後どう学んだらよいかということを中心に書いてみたいと思います。 短いまとめ： HTTPSへの安全意識が高まっている今だからこそ『プロフェッショナルTLS&PKI』を読みましょう。 長文注意！： 書いているうちに非常に長文(1万字以上)になってしまったので、長文が苦手な方は、GPT-4要約(400字)を
Anchor: Effortless Encryption
New to encryption?We’ll have you set up in no time. Anchor seamlessly adds encryption to your application without complicated choices or tradeoffs. Seasoned security developer?Use the tools and workflows you know and love. Anchor uses ACME for certificate provisioning, a CLI for local development, and moves trust store management into CI/CD pipelines. Part of an Organization?Save countless hours o
逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse
パケットキャプチャで理解する TLS1.3
TLS は Transport Layer Security の略で、盗聴、あるいは通信相手のなりすましの可能性がある通信路において、安全に通信を行うための暗号通信プロトコルです。 本書では、Go 言語を使って TLS サーバ・クライアントを用意し、その通信を Wireshark で観察しながら、TLS のプロトコルについて説明します。 本書を読むことで、TLS の通信で実際にどのようなパケットが送受信されているかが確認でき、TLS の学習の助けになると思います。 また、TLS には複数のバージョンがありますが、本記事では、最も広く使われており、かつ最新である TLS1.3 に焦点を当てます。
TLSの符号化 - あどけない話
TLSのデータがどう符号化(シリアライズ)されるかのメモ。簡単にいうと可変長配列だけ先頭に「長さ」が付き、それ以外はそのまま。 基本型 たとえば、ProtocolVersionは uint16 と定義されている。 uint16 ProtocolVersion; TLSのバージョン1.3の値は、0x0304であり、そのままネットワークバイトオーダー(ビッグエンディアン)で符号化される。 03 04 # TLS 1.3 固定長配列 固定長配列は、角括弧を使って表す。 たとえば、CipherSuiteが以下のように2バイトで定義されている。 uint8 CipherSuite[2]; TLS_AES_256_GCM_SHA384 は 0x1302 と定義されている。 13 02 # TLS_AES_256_GCM_SHA384 可変長配列 可変長配列は、小なり大なりで表す。小なり大なりの中に、長
Mutual TLS now available for Workers
In today’s digital world, security is a top priority for businesses. Whether you’re a Fortune 500 company or a startup just taking off, it’s essential to implement security measures in order to protect sensitive information. Security starts inside an organization; it starts with having Zero Trust principles that protect access to resources. Mutual TLS (mTLS) is useful in a Zero Trust world to secu
Go の HTTP クライアントで mTLS を利用する
mTLS を利用することで、クライアント・サーバー間で強固な認証の仕組みを簡単に導入することができます。 今回は Go で書いたバッチ処理の結果を Cloudflare Workers 経由でデータベースに保存した歳に、 Go から Cloudflare Workers へのアクセス制御に Cloudflare mTLS を採用したので、まとめておきました。 個人的に mTLS (Clouddflare mTLS) を流行らせたいという思いもあります。 Go のコード package main import ( "crypto/tls" "crypto/x509" "io" "log" "net/http" "net/url" "os" "time" ) const ( // mTLS を有効にして保護している URL // クライアント証明書が無い状態でアクセスするとエラーコード 102
ISP Column - October 2022
There is a common view out there that the QUIC transport protocol (RFC 9000) is just another refinement to the original TCP transport protocol [1] [2]. I find it hard to agree with this sentiment, and for me QUIC represents a significant shift in the set of transport capabilities available to applications in terms of communication privacy, session control integrity and flexibility. QUIC embodies a
Cloudflare で mTLS を利用する
Cloudflare で mTLS を利用するのがあまりにも簡単だったので書いておきます。 mTLS について 一般的に TLS を利用する場合は「クライアントがサーバーから送られてきた証明書を検証する」という仕組みを利用し、 信頼できる機関が発行した証明書を利用しているかどうかや証明書のドメインが一致しているかどうかなどを確認します。 mTLS (mutual TLS) というのは TLS 利用時に「クライアントから送られた証明書をサーバが検証する」という仕組みです。 つまりサーバーがクライアントがわから送られてくる証明書を確認するというフェーズが挟み込まれます。 この証明書自体は何を使ってもよく、オレオレ証明書でもかまいません。 クライアント側に証明書を設定するという仕組みです。VPN とかを利用したりする方は経験があるかもしれません。 mTLS はめんどくさい クライアント側に証明書
Planning Go 1.20 Cryptography Work
12 Sep 2022 Planning Go 1.20 Cryptography Work As you might know, I left Google in spring to try and make the concept of a professional Open Source maintainer a thing. I'm staying on as a maintainer of the Go cryptography standard library, and I am going to seek funding from companies that rely on it, want to ensure its security and reliability, and would like to get a direct line to the maintaine
HTTPS 証明書の Common Name の検証がしれっと禁止されていた件について | IIJ Engineers Blog
開発・運用の現場から、IIJのエンジニアが技術的な情報や取り組みについて執筆する公式ブログを運営しています。 こんにちは。IIJ Engineers Blog編集部です。 IIJの社内掲示板では、エンジニアのちょっとした技術ネタが好評となって多くのコメントが付いたり、お役立ち情報が掲載されています。 今回は、すでにお気づきの方もいるかもしれませんが、いつの間にか HTTPS 証明書の Common Name の検証が禁止 になっていた件について紹介します。 HTTPS 証明書の検証手続きは、RFC2818 で「Subject Alternative Name があればそれで、なければ Common Name を見よ」となっていました。 If a subjectAltName extension of type dNSName is present, that MUST be used as
RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens Abstract This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either
Caddy | ふうせん🎈 FU-SEN
Web サーバ Caddy（キャディ）についてまとめています。 2020年5月、Caddy 2.0.0 が正式公開されました。 2022年9月には Caddy 2.6.0 が公開されています。 開発はすでに Caddy v2 で更新され、v1 はセキュリティ的な修正に留められます。 そのため、基本的には Caddy v2 での使用がおすすめです。 Caddy v2 と Caddy v1 で異なるところがいくつか存在します。 公式 Web サイトは Caddy v2 向けに置き換えられていて、 Caddy v1 はマニュアルのアーカイブなど、一部情報が残されています。 Caddy 関連で検索する場合など、 Caddy v2・Caddy v1 どちらの記載か注意して参照して下さい。 目次Caddy 2.7 の注意ページ運営者や周辺の利用者による報告、また公式 GitHub Issues や
Let’s Encryptでワイルドカード証明書を取得する話 | IIJ Engineers Blog
はじめに SoftwareDesign 8月号のDNS特集にて記事を書かせていただきました。みんな買ってね。 で、実は最初に書いてた原稿はもっと長かったんですけど、紙幅の都合で一部の内容については掲載を見送りました。せっかく書いたのに捨てるのはもったいないので、先日おこなわれたDNS Summer Day 2022で発表しようかと準備してたんですが、途中で気が変わって違う内容になりました。そんなわけで、最終的にエンジニアブログにて供養します。加筆修正しまくっているので元の原稿の気配はもはや残り香程度に漂うだけですが。 ACMEでdns-01チャレンジ サーバ証明書を無料かつ自動で取得できるサービスとして有名なものにLet’s Encryptがありますが、Let’s Encryptの仕組みはLet’s Encrypt独自のものではありません。ACME (RFC8555)として標準化されていて
Tracing TLS Traffic — eBPF style
IntroductionTLS traffic inspection — the holy grail of any troubleshooter deep in the network stack scratching his head in despair, or the chance for stealing confidential data and profiting in the black market for a more ill intended user. Let me clarify before we move on. This article does not showcase or explain any way to intercept TLS traffic using man-in-the-middle…
golangで作るTLS1.3プロトコル
はじめに 前回までの記事でTLS1.2プロトコルスタックを自作してみました。 ただ皆さんご存知の通り、TLS1.2の脆弱性の対策やQUICなど新しいプロトコルへの対応を考慮して設計したTLS1.3が2018年にリリースされ普及が進んでいます。 使用率ではまだTLS1.2が一般的ですが今後は1.3へと置き換えが進んでいくと、どこかの時点で逆転するのでしょう。そのときに慌てて学ぶよりも、今1.3も実装して学ぶことにします😊 まぁ1.2作れたしイケるでしょう(死亡フラグ😇😇😇) 今回の実装方針です。 crypto/tls は一切使わずTLS1.3のフルハンドシェイクをオレオレで実装する 使える部分は前回までのTLS1.2の実装を再利用する cipher suitesは TLS_CHACHA20_POLY1305_SHA256 を使う TLS1.3でハンドシェイクしてからnginxにHTT
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google、Androidに「DNS over HTTP/3」対応を追加 ～実装はRust言語／既存の「DNS over TLS」よりも高いパフォーマンス
GitHub - gojue/ecapture: Capture SSL/TLS text content without a CA certificate using eBPF. This tool is compatible with Linux/Android x86_64/aarch64.
drwetter/testssl.sh: Testing TLS/SSL encryption anywhere on any port
