Let’s Encryptの短期証明書はかなり厳しいのでARI対応クライアントを使った方がよい
Let’s Encryptの短期証明書は、90日証明書の延長くらいの感覚で入るとかなり厳しいです。 サブドメインを含む複数の証明書を短い間隔で発行・更新する構成では、証明書発行まわりのレート制限に引っかかりやすくなります。短期証明書では更新回数が増えるので、その影響がかなり表面化しやすくなります。 まずステージング環境で試した方がよい 開発やテストでは、本番ではなくステージング環境を使った方がよいです。本番と同じ種類の挙動をかなり緩い制限で試せるので、証明書の切り方や更新方法を確認する段階では先にこちらを使う方が安全です。 環境 ACME directory URL 短期証明書はレート制限に当たりやすい 短期証明書は有効期限が160時間しかなく、Let’s Encryptは3日ごとの更新を勧めています。90日証明書より更新回数が大きく増えるので、レート制限に当たりやすくなります。 特に厳し
HTTPS 証明書クロニクル | blog.jxck.io
Intro Web サービスをデプロイする際に、CA から証明書を取得し HTTPS で暗号化するのが一般的となった。 かつては "SSL 証明書" として、メールでやり取りし有料で購入するのが常識だったが、自動/無料で取得することが増えた。かつては 5~10 年あった有効期限もどんどん短くなり、今では 6 日の証明書も発行されている。 このように、証明書を取り巻く変遷は目覚ましく、それは Web を取り巻く環境の劇的な変化を色濃く反映した結果と言える。 http:// が https:// になった裏で何が起こり、これからどうなっていくのか。まとめていく。 (極力ソースを付記するが、既に消えて WebArchive にも残っていないものも多く、筆者の記憶に頼る情報も多い。) 黎明期 (90 年代後半~2010 年頃) 90 年代の終わり頃、当時は TLS の前身にあたる SSL のデプロ
公衆WiFiでのMITMの脅威について、HTTPSなら心配不要というのはわかるのですが、汎用的なブラウザではなく専用のモバイルアプリの場合、HTTPSの検証結果を無視するものが一定割合あるという調査結果を見た記憶があります。 そのようなアプリに対してDoH/DoTは対策になりますか？ | mond
DNSの完全性を確保しても、公衆Wi-FIの偽アクセスポイント（Evil Twin）を用いたMITM攻撃の緩和はできないです。その理由は、DNSの操作をしなくてもMITM攻撃はできるからです。 私の以前のブログ記事が参考になると思います。 https://blog.tokumaru.org/2013/09/cookie-manipulation-is-possible-even-on-ssl.html HTTPSを使ってもCookieの改変は防げないことを実験で試してみた寺田さんのブログエントリ「 他人のCookieを操作する 」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えるこ... blog.tokumaru.org
新人エンジニアのための今度こそ理解するSSL/TLS超入門
はじめに Web開発やインフラに関わっていると、必ず目にするのがHTTPSです。 今や「HTTPではなくHTTPSが当たり前」という世界になっています。 一方で、こんな経験はありませんか？ 証明書エラーが出たけど、よく分からず無視した 「オレオレ証明書」と言われてもピンとこない HTTPSなのに「安全ではありません」と表示されて混乱した SSL/TLSは使うことは簡単ですが、何が起きているかを理解するのは意外と難しい技術です。 特に新人エンジニアのうちは、 「HTTPS ＝ 暗号化されていて安全」 というイメージだけで通り過ぎてしまいがちです。 しかし実際の SSL/TLS は、暗号化だけでなく「相手が本物かどうか」を確認する仕組みでもあります。 この記事で扱うこと・扱わないこと この記事では、SSL/TLS を 次の視点 から説明します。 TLSは何を守っているのか サーバーはどうやって
【理論編】HTTPS通信の中身を見て、どのようにしてセキュアな通信が確立されるかを理解する | フューチャー技術ブログ
こんにちは、CSIG 所属の市川です。普段は FutureVuls という脆弱性管理サービスの開発・カスタマーサポートをしています。 「ん？そういえば、HTTPS 通信 (HTTP over SSL/TLS) では実際どのようにセキュアな通信が確立されているんだろう？」 と、ふと気になってしまうこと、ありませんか？私はありました。 というわけで、SSL/TLS について書籍などで学んでみたのですが… アルゴリズムが沢山出てきて頭がこんがらがる…。結局どのフェーズでどのアルゴリズムが使われているんだろう？ TLS ハンドシェイクの中では、実際どういった通信が行われているのだろうか。ハンドシェイク確立後はちゃんと暗号化されているのだろうか。 …というモヤモヤが残りました。 本記事 (理論編) と、続編の実践編で、この2点の疑問を解決していきます。 本記事でやりたいこと本記事 (理論編) では、
世界最大の認証局Let's EncryptがOCSPサポート停止、企業ユーザーにも影響
Webサーバーで使うサーバー証明書の発行数が世界最多の認証局Let's Encrypt（レッツエンクリプト）は2024年7月23日、衝撃的な声明を発表した。サーバー証明書の有効性を確認するメジャーなプロトコル「OCSP（Online Certificate Status Protocol）」のサポートを終了する意向を示したのだ。
Wiresharkで観察して理解するHTTPS（HTTP over TLS）の仕組み - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに HTTPS(HTTP Over TLS)とは SSL/TLS HTTPSの流れ 実際に通信を観察 自己署名証明書の用意 サーバーの作成 WireSharkの準備 リクエストを送信して観察 まとめ はじめに エンジニア２年目のTKDSです！ 普段何気なく使ってるほとんどのWebサイトが対応しているHTTPS通信の仕組みについて調べてみました。 本記事では、Wiresharkを用いてHTTPSの内部動作を解析し、どのようにしてデータが保護されているのかを具体的に解説します。 記事の後半では、Wiresharkを使って実際の通信データを観察し、暗号化プロセスの詳細を確認してみます。 HTTPS(HTTP Over TLS)とは HTTPS(HTTP Over TLS)は、HTTPの暗号化版で、ウェブサイトとブラウザ間の安全な通信を実現するプロトコルです。 TLSを使用して、HTTP通信
SSL/TLS実践入門 | 技術評論社
概要 SSL/TLSは、通信の秘密を守るために利用されている通信プロトコルです。HTTPSやHTTP/3にも利用されており、今日のWebでは利用が一般的になっています。本書では、その最新バージョンであるTLS 1.3のしくみと、その使い方を解説します。SSL/TLSは公開されている実装例などを真似すれば基本的な動作はさせられますが、それを応用していくには技術に関する理論の理解が必須になります。しかしSSL/TLSに関連する技術は大変多く、かつそれらのドキュメントは不足している状態です。本書ではこの理論部分を丁寧に解説し、それを活かした形で実装例まで解説することで、Web開発者たちが望んでいる解説と実践を相互に接続します。 目次 第1章 SSL/TLSの世界へようこそ 暗号化の役割と重要性 インターネットに暗号化が必要な理由 情報の秘匿 認証 SSL/TLSの歴史 暗号技術の成り立ち SSL
Google Chrome、全ユーザーに対しHTTPからHTTPSへ自動変更
Bleeping Computerは10月30日(米国時間)、「Google Chrome now auto-upgrades to secure connections for all users」において、GoogleがすべてのChromeユーザーに対し、HTTPリクエストを自動的にHTTPSリクエストに変更する「HTTPSアップグレード」を開始したと報じた。Googleはこれまでにも同機能を限定的に展開していたが、2023年10月16日に安定版のすべてのユーザーが対象になったという。 Google Chrome now auto-upgrades to secure connections for all users 歴史的に、ブラウザはHTTPSをサポートするサイトにおいて安全ではないHTTPリクエストを行うことがある。Google Chromeでは、次のような条件でHTTPリソー
日経XTECH曰く「SSL証明書の発行者がLet's Encryptならまず詐欺」 | スラド セキュリティ
技術系メディアの日経クロステック (xTECH) が 4 日に公開した「偽サイトもアドレス欄に鍵マーク、証明書を確認してフィッシング詐欺を見抜こう」という記事が問題になっているので共有したい (はてなブックマーク)。 問題になっているのは、現代では SSL の有無だけで本物かどうか判断できないため証明書の種類を見るべきだとする以下のような記述。 このうち詐欺で悪用されるのがDV証明書。「Let's Encrypt」という認証局では無料で発行しており、フィッシング対策協議会によれば、一部の例外を除いて大半のフィッシングサイトでこの証明書が利用されているという。大手企業が利用するケースは考えにくい。ブラウザーの証明書ビューアーで、発行者が「Let's Encrypt」ならまず詐欺なので用心しよう。
OpenSSLに複数の重大な脆弱性、ただちに更新を - JPCERT/CC
JPCERTコーディネーションセンター(JPCERT/CC: Japan Computer Emergency Response Team Coordination Center)は2月8日、「JVNVU#91213144: OpenSSLに複数の脆弱性」において、OpenSSLに重大なセキュリティ脆弱性が複数存在すると伝えた。これら脆弱性が悪用されると、サービス運用妨害(DoS: Denial of Service)を受けたり、ユーザーがサーバへ送信したアプリケーションのデータを復号されたりする危険性がある。 JVNVU#91213144: OpenSSLに複数の脆弱性 脆弱性の詳細は、OpenSSLプロジェクトによる次のセキュリティアドバイザリにまとめられている。 OpenSSL Security Advisory [7th February 2023] 脆弱性が存在するとされるプロダ
やはり俺の情報教科書はまちがっている。 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 目次 はじめに 個人を特定する情報が個人情報じゃない デジタル署名は暗号化しない TLS(SSL) は共通鍵を公開鍵で暗号化しない TLS(SSL) が使われていれば安全じゃない 変数は箱じゃない Python 等は「ソースコードを 1 行ずつ実行するインタプリタ方式」じゃない 日本語 1 文字は 2 バイトじゃない 動画が動いて見えるのは残像によるものじゃない 標本化定理は「2 倍以上の周波数」じゃない その他いろいろ はじめに 2022 年から高等学校で、プログラミング等を学ぶ「情報Ⅰ」が 必修 必履修科目になりました。1 さらには
TCPとQUICの比較
ジェフ・ヒューストンのブログより。 QUICトランスポート・プロトコル(RFC 9000)は、オリジナルのTCPトランスポート・プロトコルを改良したものに過ぎないという一般的な見解があります[1][2]。私は、この意見に同意し難く、私にとってQUICは、通信のプライバシー、セッション制御の完全性、柔軟性の面で、アプリケーションが利用できるトランスポート機能における重要な変化を象徴しています。QUICは、より多くの形式のアプリケーションの動作に本質的に役立つ、異なる通信モデルを体現しています。そうです。TCPよりも高速です。私の意見では、公衆インターネットは、いずれQUICがTCPに取って代わると思っています。ですから、私にとってQUICは、TCPに少し手を加えただけのものではありません。ここでは、TCPとQUICの両方について説明し、QUICがトランスポート・テーブルに加えた変更について見
CVE-2022-3786 and CVE-2022-3602: X.509 Email address buffer overflows | OpenSSL Library
CVE-2022-3786 and CVE-2022-3602: X.509 Email address buffer overflows Today we published an advisory about CVE-2022-3786 (“X.509 Email Address Variable Length Buffer Overflow”) and CVE-2022-3602 (“X.509 Email Address 4-byte Buffer Overflow”). Please read the advisory for specific details about these CVEs and how they might impact you. This blog post will address some common questions that we expec
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
★★再追記 レンタルサーバは、自由度が低くてストレスになるからやらない..
★★再追記 レンタルサーバは、自由度が低くてストレスになるからやらない。SQLでwith使いたいからMySQL8をって言ってもさくらレンタルサーバじゃ無理なんでしょ？ あと同居利用者のせいで高負荷ってのも避けたい。そこを気にしない人はレンタルサーバでいいと思うよ。 あと LB $0.025/h だった。月2000円くらいか。 ★追記 LBは独自ドメイン+自動更新無料SSL証明書のためね。Cloud Storageの無味乾燥なドメインでいいなら、SSL自動かつ無料でほんとに月数円。 －－－－－－－ もうねめんどくさいんだわ。もちろん以前はそうやってたよ。 PHPだのApacheだのMySQLだのインストールしたり設定ファイル置いたり、 脆弱性対応したり、SSL証明書更新したり、一応落ちてないか無料監視サービス使ったり。 でも仕事ならともかく、趣味だからこそこんなことやりたくないじゃん。 なの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Let’s Encrypt Launches IP Address Certificates With 6-Day Lifetimes
情シス激怒（げきおこ）～ Apple が SSL/TLS 証明書有効期間を短縮提案 | ScanNetSecurity
LOCAL環境でHTTPSが必要なときはlocal-ssl-proxyが便利 - Qiita
どなるどだっく on Twitter: "なんとなくコロナワクチン接種証明アプリの通信解析をしてみたんだが、アプリがサーバ証明書確認せずに情報送信してるから、SSLインスペクションで送受信データが見えてしまうんだが・・・ マイナンバーカードのRawデータが丸見えです。 https://t.co/6Ot5owQ6mD"
