東京都が2020年6月3日に開設した東京都知事選挙(2020年7月5日投開票)の特設サイトを巡って不具合が生じている。東京都選挙管理委員会のサイトに掲載された特設サイトのURLは「http://2020tochijisen.tokyo/」。TLSというセキュリティー機能を使わずにアクセスするURLである。このURLでアクセスすると、多くのWebブラウザーは「保護されていない通信」と警告を表示する。
Let's Encryptは2024年12月11日(現地時間)、2025年に迎える10周年を前に6日間有効な新しいTLS証明書の提供を開始すると発表した。同社が公開した2024年の年次報告書内で発表されたサービスとされている。 Let's EncryptはWebサイトのHTTPS化を推進する非営利団体のInternet Security Research Group(ISRG)が運営する無料の認証局だ。誰でも無料でSSL/TLS証明書を取得できるよう支援しており、Webサイトの暗号化を手軽に実現できることを目指している。 Let's Encryptが短期証明書を導入、10周年を前に新サービス提供予定 Let's Encryptは2015年のサービス開始以来、90日間有効なTLS証明書を無料で提供し続けてきた。この証明書によってWebサイトのHTTPS対応が容易になり、現在では5億以上のWe
ついにWindowsのOSレベルで「TLS 1.0/1.1」が既定で無効化へ、その影響を調査するには:企業ユーザーに贈るWindows 11への乗り換え案内(20) MicrosoftはTLS 1.0と1.1を、WindowsのOSレベルで既定で無効化することを発表しました。まずは、2023年9月のWindows 11 Insider Previewで実施し、その後、サポートされるWindowsのリリースビルドに対して実施対象が広げられる予定です。 企業ユーザーに贈るWindows 11への乗り換え案内 TLS 1.0/1.1排除の流れは数年前からのインターネットのトレンド Microsoftは2023年8月1日(米国時間)、「Windowsクライアントの非推奨の機能」のページを更新し、WindowsにおけるMicrosoftは「Transport Layer Security(TLS)」
タイトルの通りなんですが、その昔これを見つけた時はヘンな汗が噴き出ましたよ。 eapol_testを使ったEAP-TLS認証 SUCCESS... (;゚∀゚) 自分はEAP-TLSを使わないからといっても、デフォルトで穴が開くので要注意です。 不具合の内容 以下の条件がすべて満たされているとき、同一CAが発行・署名したクライアント証明書を用いて、第三者によるEAP-TLS認証が成功します。無線LANに不正に接続できたりします。 FreeRADIUSでPEAP, EAP-TTLSなどを使っている。 Public CAから発行されたサーバ証明書を使っている (Let's EncryptでもUPKIでも、何でもよい) EAP-TLSを運用していないのに、その機能が無効になっていない (FreeRADIUSのデフォルト)。 FreeRADIUSの設定ファイル mods-enabled/eap の
こんにちは、新型コロナウイルス感染症対策のためテレワーク勤務中の山田です。 テレワーク勤務に伴い通勤で運動をしなくなった分、定時後から日の入りまでちょくちょく近くの河川公園を歩いています。 ソーシャルディスタンスを保ちつつ、マスクを防備していますので息苦しいですが仕方ありません... 前置き さて、日本では新型コロナウイルスの話題が飛び交う毎日ですが、コロナの話題が出る1ヶ月ほど前主要ブラウザの「TLS1.0」と「TLS1.1」サポートが終了しようとしていたのは、ご存知でしょうか。 この業界に詳しい方であれば、既に対策済みの方がほどんどではないかと思いますが、新型コロナウイルスの世界的流行に伴い各主要ブラウザは、サポート終了時期が延期もしくは再有効化がなされています。 CentOS5系は、サポート終了しておりますOSになりますため、TLS1.2サポートの対策には6系以降のOSにリプレイスさ
図1: TLS over TCP と QUIC のスタック構造の比較はじめにQUICはTLSv1.3に相当するセキュリティを標準装備すると説明されます。図1はよく参照されるスタック構成ですが、TLSがQUICスタックの内部に埋め込まれています。縦に積み上げられた “スタック” になっていません。TLSの埋め込みは何を意味しているのでしょうか?本稿の前半ではTLSとQUICの関係と、TLSライブラリの使われ方をTLS over TCPと比較しながら解説します。後半ではOpenSSLのQUIC対応の状況についてふれます。 なお本稿で処理の流れを追う際は送信を中心に取り上げます。受信についても逆順で同様の処理が必要ですが解説は省略しています。 QUICとTLSv1.3の関係TLSには大きく分けて、ハンドシェイクプロトコルとレコードプロトコルがあります。前者は暗号スイートの調停や鍵交換、各種パラメ
ついSSL/TLS証明書の更新を忘れちゃう人へ――Kubernetesの「cert-manager」で始める証明書管理自動化入門:Cloud Nativeチートシート(29) Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、cert-managerを利用したIngressによる自己署名証明書とLet's Encryptで発行した証明書の利用方法を解説し、Gateway APIでcert-managerを利用する方法を紹介する。 もう、手動で証明書を作成、取得、設定する世界には戻れない 今やWeb公開で必須となったSSL(Secure Sockets Layer)/TLS(Transport Layer Security)ですが、素の「Kubernetes」において「Ingress」や「Gateway API」でSSL/T
ストーリー by nagazou 2022年03月15日 16時10分 ますますロシア国外情報にアクセスしにくくなりそう 部門より ロシアが独自のTLS認証局を創設したとの報道が出ている。ロシアは現在、ウクライナ侵略を受けて世界各国からさまざまな制裁を受けているが、欧米の企業や政府による制裁措置により、既存のTLS証明書を更新することができない状況に陥っている。証明書の有効期限が切れてしまえば、ブラウザ側でサイトへのアクセスがブロックされてしまう。このため独自のTLS認証局を創設し、期限切れもしくは無効化された場合の代替となる証明書を無料で発行するとしている(Bleeping Computer、TECH+)。 ロシアの公共サービスポータルである「Gosuslugi」によれば、新たなサービスでは、5営業日以内に証明書を無料サイト所有者である法人に提供するとしている。ただし、こうした新しい認証
こんにちは、技術開発室の滝澤です。 前回(2021年7月)、『TLS証明書チェッカーcheck-tls-certの公開』というエントリーを公開しました。このcheck-tls-certを開発するにあたって、テスト用のPKI(Public Key Infrastructure、公開鍵基盤)を構築しました。 opensslコマンドを利用したPKI用のスクリプトを整備したのですが、開発当時ではOpenSSL 3.0の開発が進んでいることもあり、OpenSSL 3.0でも利用できるようにとドキュメントを読んでみると、「deprecated」(非推奨)の文字が散見されました。そのため、それを踏まえたスクリプトを書きました。この際に得られた知見を本記事で紹介します。 なお、2021年9月7日にOpenSSL 3.0.0がリリースされました。 本記事を1行でまとめると次のようになります。 OpenSSL
TLS 1.0およびTLS 1.1はセキュリティ上、脆弱であると考えられており、多くのベンダが使用停止を進めている。Microsoftも同社のサービスやプロダクトにおいてTLS 1.0および1.1の使用停止を進めている。しかし、この作業は一度に進められているのではなく、サービスやプロダクトごとに個別に進められている。どのサービスでいつ利用できなくなるのか、まとまった情報は公開されていない。 Microsoftはこのほど「TLS 1.0 and 1.1 deprecation - Microsoft Tech Community - 1620264」において、同社のサービスおよびプロダクトにおけるTLS 1.0/1.1サポート廃止のタイムラインを簡単にまとめた情報を公開した。どのサービスがいつサポート廃止となるかを確認できる。 掲載されている主な情報は次のとおり。
IETFで、TLS1.0とTLS1.1を正式に非推奨にする「RFC 8996 Deprecating TLS 1.0 and TLS 1.1」が公開されました。 新しいプロトコルへの移行期間は十分であるとし、TLS1.0, TLS1.1, DTLS1.0は廃止となり、TLS 1.2, TLS1.3, DTLS 1.2のみが使用できます。表現としても、MUST NOTで利用を禁止しています。 TLS 1.0 MUST NOT be used TLS 1.1 MUST NOT be used 2015年に公開された、TLS利用時の推奨事項を定めたRFC7525がありますが、今回の禁止内容も含めて改定作業が開始されています。詳細については以前書いたとおり asnokaze.hatenablog.com 更新されるRFC RFC 8996では、既存のRFCについても言及しており TLS1.2以上で
ウクライナ侵攻を続けるロシアに対して各国政府や民間企業が数多くの制裁措置を発表しており、ロシアでシェア1位と2位のインターネットプロバイダーが相次いでサービス停止を発表するなどインターネット環境にも影響が出始めています。制裁の影響でロシアではデジタル証明書が更新不能になる事態が発生しており、この問題を解決するべくロシア独自のTLS認証局が開設されました。既に独自認証局による認証済みのウェブサイトが複数登場しており、ロシアによる通信の傍受が懸念されています。 Russia creates its own TLS certificate authority to bypass sanctions https://www.bleepingcomputer.com/news/security/russia-creates-its-own-tls-certificate-authority-to-b
* Kernel version must be 5.10, not 4.14; see OSs That Do Not Support kTLS and the Amazon Linux 2 FAQ ** Inherits its kTLS support status from RHEL 8 as its upstream source *** See the FreeBSD commit log OSs That Do Not Support kTLS The following OSs do not support kTLS, for the indicated reason: Alpine Linux 3.11–3.14 – Kernel is built with the CONFIG_TLS=n option, which disables building kTLS as
以下で公開されているアドバイザリー通り、今月末の 10/31 に Azure では全体的に TLS 1.0 と TLS 1.1 のサポートが廃止され、11/01 からは各種 Azure サービスを利用するためには TLS 1.2 以上が必須となります。 対象となるサービスが非常に多いため、影響範囲も広くなりがちですが殆どのケースでは問題ないでしょう。 既に大半のトラフィックは TLS 1.2 が使われているはずですが、TLS 1.2 をサポートしていない古い環境の存在や .NET Framework を使っている場合は明示的に TLS 1.2 を回避する設定が流行った時があるため、いま一度見直しておくのが良さそうです。 一部のサービスでは Azure へのリクエスト時だけではなく、Webhook による Azure から外部へのリクエスト時にも適用されるため、受け側も TLS 1.2 への
Bleeping Computerは3月10日(米国時間)、「Russia creates its own TLS certificate authority to bypass sanctions」において、ロシア当局が独自のTLS認証局を創設したと伝えた。同局は国外の証明書が期限切れまたは無効化された場合にその置き換えとなる証明書を無料で発行し、通常5営業日内で必要に応じて提供するとしている。 Russia creates its own TLS certificate authority to bypass sanctions これはロシアのサイトが既存のTLS証明書を更新することができず、Webブラウザによるアクセスがブロックされ始めている事態に対処するためとされている。欧米の企業や政府機関は制裁措置の一環として、ロシアサイトに対するTLS証明書更新の支払い処理を受け付けておらず、
「TLS 1.2」以前において、「Diffie-Hellman(DH)鍵交換」を利用している場合に、暗号化された通信が解読可能となる攻撃手法「Raccoon Attack」が明らかとなった。マイクロソフトは、9月の月例パッチで対処しており、「OpenSSL」やF5の「BIG-IP」の旧バージョンなども影響を受けるという。 「TLS 1.2」以前において「DH鍵交換」を利用している場合に、中間者攻撃によって「TLSハンドシェイク」における「プリマスターシークレット」を特定することが可能となる脆弱性が明らかとなったもの。 ルール大学ボーフムやテルアビブ大学、パーダーボルン大学などの研究者が発表した。攻撃手法は「Raccoon Attack」と名付けられている。特に頭文字などより名付けられたわけではなく、ロゴには「Raccoon」が意味するアライグマがあしらわれている。 同脆弱性では、複数のTL
2021-10-31 はじめに OpenSSLのSSL_sendfileとパッチを当てたnginxでLinuxのkTLSを試してみた · hnakamur’s blog を書いてから1年半経って状況が変わっていたので再度試してみました。 9日前に SSL: SSL_sendfile() support with kernel TLS. · nginx/nginx@1fc61b7 で Linux の kernel TLS を使って sendfile するコードが nginx に入っていました。 コミットメッセージによると enable-tls オプションを有効にした OpenSSL 3.0 が必要とのことです。 検証環境 $ cat /etc/os-release | grep ^VERSION= VERSION="20.04.3 LTS (Focal Fossa)" $ uname -r
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
* Trying 127.0.0.1:8000... * Connected to localhost (127.0.0.1) port 8000 (#0) * h2h3 [:method: GET] * h2h3 [:path: /] * h2h3 [:scheme: http] * h2h3 [:authority: localhost:8000] * h2h3 [user-agent: curl/7.88.1] * h2h3 [accept: */*] * Using Stream ID: 1 (easy handle 0x561bf2f5dce0) > GET / HTTP/2 > Host: localhost:8000 > user-agent: curl/7.88.1 > accept: */* > < HTTP/2 200 < content-type: text/plai
JPCERTコーディネーションセンター(Japan Computer Emergency Response Team Coordination Center:JPCERT/CC)は9月14日、「JVNTA#95716145: TLS 1.2 およびそれ以前の Diffie-Hellman 鍵交換に対する攻撃手法について (Raccoon Attack)」において、TLS (Transport Layer Security) 1.2 およびそれ以前のバージョンについて、鍵交換手順にDiffie-Hellmanが使われる場合に中間者攻撃によりpre-master secretを解読する攻撃手法が公開されたと伝えた。この攻撃手法は「Raccoon Attack」と呼ばれている。 Raccoon Attackに関する情報は次のページにまとまっている。 Raccoon Attack Raccoon
baba 高校時代から趣味でプログラミングを始め,そのままずっとコードを書いています。2010年SFC卒業,在学中にBPS入社。ゲームなどの趣味プログラミング,Webシステム,スマホアプリ,超縦書エンジン(C++/Chromium),Webフロントエンド(TypeScript/React)などを主にやってきました。最近は自社製品(超シリーズ,くんシリーズ)の開発に関わるお仕事が中心です。管理業務もしますが,ゆとりプログラマーなので気楽にPCに向かっているのが好きです。 情報処理技術者試験(16区分 + 情報処理安全確保支援士試験),技術士(情報工学部門),中小企業診断士、Ruby Programmer Gold,AWS Certified Solutions Architect - Professional,日商簿記2級,漢検準1級。情報処理技術者試験 試験委員(2021-)。 babaの
CDNやDDoS防御などのサービスを提供しているCloudflareが、配信元サーバーへの接続においてSSLおよびTLSが利用可能かどうかを自動で判断する「Automatic SSL/TLSモード」を導入したと発表しました。 Introducing Automatic SSL/TLS: securing and simplifying origin connectivity https://blog.cloudflare.com/introducing-automatic-ssl-tls-securing-and-simplifying-origin-connectivity Cloudflareはユーザーとサーバー間のリバースプロキシとして動作し、世界各地のユーザーからのアクセスを最も近い距離にあるエッジサーバーで処理することで高速な応答を可能にしています。リクエストされたデータがエッジ
2020年9月1日以降、Chrome、Safari、Firefoxといった主要ブラウザで、SSL/TLS証明書の有効期限が最大13か月間(398日間)に制限される(マイナビ)。変更された経緯は過去記事にもあるように、2020年3月3日にAppleが発表した方針に、GoogleやMozillaも同調、各ブラウザが有効期限を最大398日間にする方針を固めたことにある。 これまでは最大825日間(約27か月間)だったが、2年以上も期間、証明書の所有者の会社名や氏名などの情報が更新されないことになり、セキュリティ上の問題があったとされる。13か月と1年より少し長いのは更新に猶予を持たせるためで、SSL/TLS証明書の有効期間は事実上は1年間という考えであるという。今回、実質的に1年間に制限することにより、SSL/TLS証明書に問題が発見された場合の対応がしやすくなるとしている。 2020年9月1日
2020年9月1日以降、SSL/TLS証明書の購入を考えているのであれば注意が必要だ。SSL/TLS証明書は有効期間が長いほうがディスカウント率が高い。管理の手間を考えても、できるだけ長い有効期間のSSL/TLS証明書を購入するのはロジカルな選択肢だ。しかし、2020年9月1日以降は状況が一変する。 Google Chrome、Apple Safari、Mozilla Firefoxが398日間を超える有効期間を持つSSL/TLS証明書を信頼しなくなるからだ。この長さは1年間に多少の更新猶予期間を持たせたものであり、基本的にSSL/TLS証明書の有効期間の上限が1年間に限定されることになる。 どのような流れでこういった状況になったのかは、「Apple to Enforce 1-Year Limit on SSL/TLS Certificate Lifetimes on September
JVNTA#95716145 TLS 1.2 およびそれ以前の Diffie-Hellman 鍵交換に対する攻撃手法について (Raccoon Attack) TLS (Transport Layer Security) 1.2 およびそれ以前の鍵交換手順で Diffie-Hellman が使われる場合に対し、中間者攻撃により pre-master secret を解読する攻撃手法 (Raccoon Attack) が報告されています。 TLS (Transport Layer Security) 1.2 およびそれ以前の鍵交換手順で Diffie-Hellman が使われる場合に対し、中間者攻撃により pre-master secret を解読する攻撃手法 (Raccoon Attack) が報告されています。 TLS の暗号化通信では、共有鍵暗号系アルゴリズムによる暗号化を行います。ク
Amazon Relational Database Service (Amazon RDS) has new certificate authorities with 40 year and 100 year validity. SSL/TLS certificates enable secure communication between your clients and databases. Administrators can control which certificate their organization uses by setting a default certificate per account with a choice of RSA 2048, RSA4096, and ECC384. When provisioning and modifying a dat
Simone Basso (OONI), Gurshabad Grover and Kushagra Singh (Centre for Internet and Society, India) 2020-07-08 This report investigates Transport Layer Security (TLS)-based blocking in India. Previous research by the Centre for Internet & Society, India (CIS) has already exposed TLS blocking based on the value of the SNI field. OONI has also implemented and started testing SNI-based TLS blocking mea
まとめ SSL/TLSの機能ってなに? 通信相手を識別し、なりすましを防ぐ 「認証」 ※識別できても通信内容を差し替えられると意味がないので 「改ざん検知」 もある 通信内容の漏洩を防ぐ 「暗号化」 SSL/TLSってどんな技術? 鍵交換・認証・暗号化・メッセージ認証コードの4要素のハイブリッド暗号 認証のために、サーバ証明書 ( サーバ用の公開鍵証明書、SSL証明書とも ) を使用する サーバ証明書の信頼性を担保するPKIの仕組みも考えると全部で5要素 公開鍵暗号と共通鍵暗号のハイブリッド? そう覚えている人は一旦忘れた方がいい SSL/TLSで意識することってなに? 大事なのはドメイン名。なぜなら認証・PKIで 「通信相手がドメイン名通りのサイトであること」 を保証する技術だから DVとかEVとか色々あるけど、証明書の種類は正直割とどうでもいい サーバ証明書は「ドメイン名の示すサイトの
こんにちは。GMOアドマーケティングのH.Tと申します。 担当しているプロダクトでセキュリティチェックの一環として現在受け付けているリクエストのTLSバージョンや暗号スイートを洗い出す必要がありました。 GCPのロードバランサのカスタムヘッダという機能から確認できたのでご紹介します。 システム構成は以下のような感じです。 External HTTP(S)load balancer → サーバレスNEG → Cloud Run(Goアプリ) 以下Cloudコンソールでの手順になります。 先に公式ドキュメントを読みたい方はこちら 1. ロードバランサ一覧より対象のロードバランサ名をクリックして詳細を開く。 2. 「ロードバランサの詳細」画面から「編集」を開く。 3. 「バックエンド サービス」で対象バックエンドの鉛筆アイコンから「バックエンド サービス」の編集を開く。 4. 下の方にスクロール
通信経路上の暗号化について 加瀬正樹氏(以下、加瀬):次はこの紹介した手段の中で、特に通信の暗号化、Eについて、櫻庭さんから詳しい技術的な解説や最新の情報をプレゼンしてもらいたいと思います。櫻庭さん、よいでしょうか? 櫻庭秀次氏(以下、櫻庭):では、私から通信経路上の暗号化について、技術の概要になると思いますが、データ保護のメール技術に特化して話したいと思います。 話す内容は、SMTP上の暗号化といえばSTARTTLSという、みなさん知っているTLS用の暗号化通信です。それに関連したところと、あとDANE。また、これらをサポートするための技術として、MTA-STSとTLSRPTについて紹介します。 SMTPが使われる局面 SMTPが使われる局面はみなさん知っているとは思いますが、改めて説明すると、1つは、MUA(メーラー)からMSA、Submission Agentです。投稿サーバーに対し
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く