GitHub - aws/s2n-quic: An implementation of the IETF QUIC protocol
s2n-quic is a Rust implementation of the IETF QUIC protocol, featuring: a simple, easy-to-use API. See an example of an s2n-quic echo server built with just a few API calls high configurability using providers for granular control of functionality extensive automated testing, including fuzz testing, integration testing, unit testing, snapshot testing, efficiency testing, performance benchmarking,
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
mTLSとは？| 相互TLS | Cloudflare
「TLS」はインターネットなどのネットワークにおいて、セキュリティを要求されるデータ通信を行うプロトコルの一種です。TLSの古いバージョンであるTLS1.0、TLS1.1には多数の脆弱性があると指摘されていたため、主要なブラウザは安全性向上のためにTLS1.0、TLS1.1を無効化することを決定しています。Mozillaが開発するFirefoxも、2020年3月11日に正式版がリリースされた「Firefox 74」でTLS1.0、TLS1.1を無効化しましたが、「新型コロナウイルス感染症の影響で再びTLS1.0、TLS1.1を有効にした」と報じられています。 Firefox 74.0, See All New Features, Updates and Fixes https://www.mozilla.org/en-US/firefox/74.0/releasenotes/ TLS 1.
この記事は さくらインターネット Advent Calendar 2019 5日目の記事です。 さくらインターネット研究所の大久保です。 昨日公開した前編では、弊社のIaaSであるさくらのクラウド上で提供している「エンハンスドロードバランサ」機能について、概要と全体構成の紹介をさせていただきました。 後編となる本稿では、システムを構成する各パーツの詳細について引き続き紹介したいと思います。 VIPフェイルオーバ機能について 今回まずはじめに、DDoS攻撃対策として実装した機能について紹介します。 が、あらかじめ申し上げておきますと、これでどんなDDoSにも完璧に対応できます！ というものではありません 😇 一般的なDDoSミティゲーションの仕組みでは、DPI(Deep Packet Inspection)を用いて攻撃トラフィックのみを抽出破棄し、正常なトラフィックのみを通過させることが行
GitHub - opencoff/go-tunnel: TLS/SSL Tunnel - A modern STunnel replacement written in golang
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
通信経路上の暗号化について 加瀬正樹氏（以下、加瀬）：次はこの紹介した手段の中で、特に通信の暗号化、Eについて、櫻庭さんから詳しい技術的な解説や最新の情報をプレゼンしてもらいたいと思います。櫻庭さん、よいでしょうか？ 櫻庭秀次氏（以下、櫻庭）：では、私から通信経路上の暗号化について、技術の概要になると思いますが、データ保護のメール技術に特化して話したいと思います。 話す内容は、SMTP上の暗号化といえばSTARTTLSという、みなさん知っているTLS用の暗号化通信です。それに関連したところと、あとDANE。また、これらをサポートするための技術として、MTA-STSとTLSRPTについて紹介します。 SMTPが使われる局面 SMTPが使われる局面はみなさん知っているとは思いますが、改めて説明すると、1つは、MUA（メーラー）からMSA、Submission Agentです。投稿サーバーに対し
Transition to ISRG's Root delayed until Jan 11 2021
[Edit September 2020: I’ve updated the change date in this post to refer to the current plan, to make it easier to find] We’re going to delay the transition to ISRG’s root a little further, to January 11 2021. The patterns of Android adoption have not significantly improved since last year. According to numbers from Android Studio, only 66% of Android users are on version 7.1 or above, which inclu
SSL/TLSの基本 - Qiita
まとめ SSL/TLSの機能ってなに? 通信相手を識別し、なりすましを防ぐ 「認証」 ※識別できても通信内容を差し替えられると意味がないので 「改ざん検知」 もある 通信内容の漏洩を防ぐ 「暗号化」 SSL/TLSってどんな技術? 鍵交換・認証・暗号化・メッセージ認証コードの4要素のハイブリッド暗号 認証のために、サーバ証明書 ( サーバ用の公開鍵証明書、SSL証明書とも ) を使用する サーバ証明書の信頼性を担保するPKIの仕組みも考えると全部で5要素 公開鍵暗号と共通鍵暗号のハイブリッド? そう覚えている人は一旦忘れた方がいい SSL/TLSで意識することってなに? 大事なのはドメイン名。なぜなら認証・PKIで 「通信相手がドメイン名通りのサイトであること」 を保証する技術だから DVとかEVとか色々あるけど、証明書の種類は正直割とどうでもいい サーバ証明書は「ドメイン名の示すサイトの
Google ChromeはTLSで使用されるルート証明書を伝統的にOSの証明書ストアから参照していたが、近い将来GoogleはiOS版を除いて独自のルート証明書プログラムへの移行を計画しているようだ(公式ページ)。これはFirefoxと類似のモデルである。 初期ルートストアにはLet's EncryptのISRG Root X1が含まれているので、移行が完了すればChromeがサポートするAndroid 5.0以降ではLet's Encryptの証明書の有効期限切れ問題は解消すると思われる。
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
序章1. 攻撃者の秘匿1.a Torの利用方法1.b 匿名電話番号の入手方法2. 倫理の問題2.a 無条件に行える行為2.b 倫理的に避けるべき行為2.c 法律的に行ってはならない行為3. 検索エンジンの利用と応用3.a 検索エンジン一覧3.b 特殊なクエリの発行3.c Sherlockによる複数サイトの同時検索4. Webサイトの調査4.a (前提)Webアーカイブの作成4.b ソースコードや利用している外部スクリプトの調査4.c ドメイン名のWhois照会4.d DNSレコードやIPアドレスについての調査4.e SSL/TLS証明書の調査5. Twitter(X)の調査5.a 高度な検索5.b 画像の撮影場所特定5.c FF(相互フォロー)の調査5.d 内部IDやスクリーンネーム履歴の調査5.e ツイート(ポスト)のログ作成方法5.f 鍵アカウントの調査5.g 位置情報付きツイート(ポ
例えば鍵交換を ECDHE、認証 (デジタル署名) を RSA, 共通鍵暗号を AES128, ハッシュを SHA256 とした場合、「TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256」となります。 ところが、TLS v1.3 では以下の構成となりました。AEAD とは簡単に言うと「共通鍵暗号による暗号化とメッセージ改竄検知を同時に行う」方式です。 鍵交換 (Kx) 方式と認証 (Au) 方式は削除されました。 なぜかって言うと、以下のように TLS extension (拡張属性) でネゴシエーションされることになったからです。(別に暗号化方式とセットでネゴする必要が無いことに気付いたのですね。) 鍵交換 = supported_groups extension, key_share extension認証 (デジタル署名) = signature_algori
Fine-tune your App Transport Security settings - Discover - Apple Developer
At Apple, we believe privacy is a fundamental human right. When people connect to a public Wi-Fi hotspot, they expect to use your app to send and receive data without worrying that someone in the vicinity could intercept their connection and gain access to unencrypted data. Allowing even seemingly-innocuous data to remain unencrypted can expose people to snooping and fingerprinting by anyone on th
最終更新日:2021/10/02 注意: このページが翻訳された後、英語バージョンのページがアップデートされています。 (2024/05/07) 英語で表示する ルート証明書 私たちのルートは安全にオフラインで保管されています。 私たちは次のセクションにある中間CAからサブスクライバに対してエンドエンティティ証明書を発行します。 新しいルートX2を様々なルートプログラムに送信する際に互換性を得るため、私たちはルートX1からクロス署名しました。 有効 ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1) 自己署名: der, pem, txt DST Root CA X3のクロス署名: der, pem, txt 有効、利用制限あり ISRG Root X2 (ECDSA P-384,
G Suite アップデート ブログ: デフォルトの TLS およびその他の新機能を使って Gmail のメール セキュリティを強化する
G Suite のリリース内容についての詳細 「G Suite の最新情報」というヘルプセンターのページでは、「G Suite アップデート ブログ」には掲載されていない細かな変更も含めた G Suite の新サービスや新機能についてご紹介しています。
TLS 1.2 to become the minimum TLS protocol level for all AWS API endpoints | Amazon Web Services
AWS Security Blog TLS 1.2 to become the minimum TLS protocol level for all AWS API endpoints February 27, 2024: AWS has completed our global updates to deprecate support for TLS 1.0 and TLS 1.1 versions on our AWS service API endpoints across each of our AWS Regions and Availability Zones. January 17, 2024: Over 96% of AWS service API endpoints have ended support for TLS versions 1.0 and 1.1. Over
IEモードはどうなる？ IE 11のTLS 1.0／1.1が「2022年9月下旬」から既定で無効化、その影響は？
IEモードはどうなる？ IE 11のTLS 1.0／1.1が「2022年9月下旬」から既定で無効化、その影響は？：企業ユーザーに贈るWindows 10への乗り換え案内（132） Microsoftは数年前から同社のWebサイトやサービス、ブラウザなどについて、脆弱（ぜいじゃく）性問題のある「Transport Layer Security（TLS）1.0および1.1」の利用を廃止し、より安全なプロトコルであるTLS 1.2以降への移行を進めてきました。IE 11については当初2020年中に既定での無効化が予定されていましたが、延期を繰り返してきました。いよいよ、2022年9月20日以降に無効化が実施されます。 企業ユーザーに贈るWindows 10への乗り換え案内 「2022年9月」からIE 11のTLS 1.0／1.1は既定で無効に 「Internet Explorer（IE）11」と
Apple drops a bomb on long-life HTTPS certificates: Safari to snub new security certs valid for more than 13 months
Safari will, later this year, no longer accept new HTTPS certificates that expire more than 13 months from their creation date. That means websites using long-life SSL/TLS certs issued after the cut-off point will throw up privacy errors in Apple's browser. The policy was unveiled by the iGiant at a Certification Authority Browser Forum (CA/Browser) meeting on Wednesday. Specifically, according to
山市良のうぃんどうず日記 以前はできたのに、ある日からInvoke-WebRequestでダウンロードできなくなった 筆者は「Windows Sysinternals」のユーティリティーの更新版を素早く手に入れられるように、自作のWindows PowerShellスクリプト「updatesysinternalssuite.ps1」を作成し、利用しています。作成したスクリプトは、「TechNetスクリプトセンター」で公開しています。 Install and update SysinternalsSuite by PowerShell（TechNetスクリプトセンター） このスクリプトはWindows PowerShell 5.0以降で動作します。「Invoke-WebRequest」コマンドレットは、Windows PowerShell 3.0以降で利用できますが、zipファイルの展開に利
Out now! Auto-renew TLS certificates with DCV Delegation
Out now! Auto-renew TLS certificates with DCV Delegation03/23/2023 To get a TLS certificate issued, the requesting party must prove that they own the domain through a process called Domain Control Validation (DCV). As industry wide standards have evolved to enhance security measures, this process has become manual for Cloudflare customers that manage their DNS externally. Today, we’re excited to a
BPSの福岡拠点として一緒にお仕事をさせていただいています、株式会社ウイングドアのモリヤマです。 今回のテーマはTLS対応（触れるのはHTTPS化の設定に関するお話）です！ ネットワーク/インフラエンジニアの方々の領域に、ちょっとだけ学習の手を伸ばしてみました。 本記事はTLSへの理解度が下記の様な方々が対象です❗️ とりあえず通信を暗号化するやつって事は知ってる SSL/TLS対応は行った事あるが、詳しく考えたことがない セキュリティ関連にちょっとでも強くなりたい意志のある方 背景 ずいぶん前にAmazonLinux2で構築したサーバー(趣味関連ブログ用)がふと気になり、 SSL/TLSの設定ってデフォルトのままいじってないなーどうなってんだろう🤔 そして軽い気持ちでQualys SSL Labs SSL Server Test で脆弱性スキャンしたのがきっかけでした。 結果は『B』所
参考 6.4.7. 307 Temporary Redirect | RFC 7231 – HTTP/1.1: Semantics and Content2. HSTS の問題点このHSTS、以下のようなことが起きるとかなり面倒です。 ある期間、example.com というドメインのウェブサイトを運営しているウェブサーバーが Strict-Transport-Security というレスポンスヘッダを返すよう設定されていました。その期間中にそのウェブサーバーにアクセスしたブラウザは、ブラウザ内の「HSTS適用ドメイン」に example.com を追加します。しばらくして、このウェブサイトにおいて「 https でアクセスされると何らかの問題が起きる」ことが発覚したとします。サイト運営者は http でもアクセスできるように、example.com のウェブサーバーが、Strict-Tr
DNS over TLS/HTTPS
2019/06/11 #doh_study
2021年11月10日と11日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2021」がオンラインで開催されました。そこでイ・ ビョクサン氏が、LINT（LINE Improvement for Next Ten years）という、10年先を見据えて多方面にわたって改善していくプロジェクトの中で、LINEのクライアントとサーバーの接続性向上について共有しました。後半はStreaming PushとTLSについて。前半はこちら。 使いやすいStreaming Pushとは イ・ビョクサン氏：さて次のトピックである、Streaming Pushに移りましょう。それではServer Pushの要件を思い出してみましょう。HTTP/2規格に準拠し、使いやすいものでなければなりません。さらに未承諾のPushが可能でなければなりません。
iOS 13 および macOS 10.15 における信頼済み証明書の要件 iOS 13 および macOS 10.15 では、TLS サーバ証明書に対するセキュリティ要件が新しくなります。詳しくご説明します。 iOS 13 および macOS 10.15 では、以下に紹介する新たなセキュリティ要件がすべての TLS サーバ証明書に課されます。 RSA 鍵を利用する TLS サーバ証明書および発行元の CA は、鍵長 2048 ビット以上の鍵を用いる必要がある。2048 ビット未満の鍵長の RSA 鍵を用いた証明書は、TLS 通信において信頼されなくなります。 TLS サーバ証明書および発行元の CA は、SHA-2 ファミリーのハッシュアルゴリズムを署名アルゴリズムに用いる必要がある。SHA-1 で署名された証明書は、TLS 通信では信頼されなくなります。 TLS サーバ証明書は、証明書
GitHub - heartbeatsjp/check-tls-cert: Check-tls-cert is a TLS certificate checker.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
2020.02.29 CAA Rechecking Bug - Incidents - Let's Encrypt Community Support
On 2020-02-29 UTC, Let’s Encrypt found a bug in our CAA code. Our CA software, Boulder, checks for CAA records at the same time it validates a subscriber’s control of a domain name. Most subscribers issue a certificate immediately after domain control validation, but we consider a validation good for 30 days. That means in some cases we need to check CAA records a second time, just before issuance
『プロフェッショナルSSL/TLS』特別版PDF（原著改訂第2版のTLS 1.3解説章を収録）のお知らせ 2021年2月08日 お待たせしました。事実上のTLS 1.3対応版となる『プロフェッショナルSSL/TLS 特別版PDF』の提供を、ラムダノート直販サイト登録ユーザの方向けに開始しました。 今回は、「原著改訂第2版に収録されるTLS 1.3を解説した新章」を付録として追加した特別版PDFを新たに「マイ本棚」からダウンロードしていただけます。 対象：ラムダノートの直販サイトにてユーザ登録済みで、『プロフェッショナルSSL/TLS』を購入された方 取得先：購入時のユーザアカウントでラムダノートの直販サイトにログインしていただくと、「マイ本棚」の「購入済みの電子書籍」に下記のように特別版PDFが表示されます もちろん、これから直販サイトで『プロフェッショナルSSL/TLS』を購入いただき、
連載第二回、TLS1.3の性能面での改善項目、0-RTT (Early Data) を紹介しようと思う。(0-RTT: Zero Round Trip Time) これまでのTLS/SSLの性能上の大きな悩みは、冒頭のハンドシェイクによる遅延だ。これまではハンドシェイクは、安全な暗号通信をするためのやむをえないオーバヘッドと思われていた。それが、使用条件はあるものの、通信の冒頭で暗号化されたメッセージを送れる方法が正式に認められたのだから、かなり画期的なことだと思う。特に、少しでも早くデータをサーバに届けたいIoTデバイスにとっては朗報のはずだ。 しかし実は、これを1.3の冒頭に紹介するかどうかについては少々悩ましい。というのは、Early Dataによる暗号化メッセージはセキュリティ的には安全性がやや落ちるからだ。もう少し厳密な言い方をするなら、Early Data では完全前方秘匿性(
2023年3月6日紙版発売 2023年3月6日電子版発売 大竹章裕，瀬戸口聡，庄司勝哉，光成滋生，谷口元紀，くつなりょうすけ，栃沢直樹，渥美淳一，宮川晃一，富士榮尚寛，川﨑貴彦 著 B5判／160ページ 定価2,178円（本体1,980円＋税10%） ISBN 978-4-297-13354-2 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 本書は，Webシステムのセキュリティを支える技術を幅広く解説します。具体的には，公開鍵暗号，共通鍵暗号，ディジタル証明書，電子署名，認証・認可などの基礎技術の用語や理論の説明から，それらを応用したSSL/TLS，SSH，OAu
/\ TLS 1.3 /\
This page is a biased copy of RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. It hides all sections that are unnecessary to the implementation of TLS 1.3 only. It re-creates figures and re-shapes the presentation of the original RFC. It also includes errata. The original RFC being a static document this page is up-to-date. 1. Introduction The primary goal of TLS is to provide a
TLS, byte by byte
See this page fetch itself, byte by byte, over TLS This page performs a live, annotated https: request for its own source. It’s inspired by The Illustrated TLS 1.3 Connection and Julia Evans’ toy TLS 1.3. It’s built on subtls, a pure-JS TLS 1.3 implementation that depends only on SubtleCrypto. Raw TCP traffic is carried via a serverless WebSocket proxy. Key Raw bytes in hexadecimal. Outgoing messa
平常時にどんなパケットがやりとりされるかを知っておくと、トラブルが起こったときに何がおかしいのかを発見しやすくなる。そこで、Wiresharkの使い方に慣れながら、通常のパソコンでやりとりされるパケットを見ていこう。 Part4ではインターネットの通信に使うHTTPS▼通信を取り上げる。 3つの画面領域で情報を表示 HTTPS通信は、主にWebサーバーとの通信に使う。HTTPSは、HTTP通信をTLS▼という技術を使って、安全にやりとりするようにしたプロトコル。現在のWeb通信では、従来のHTTPに代わって主流になっている。 まず、HTTPSは仕様上どのようなやりとりをすることになっているかをおさらいしておく。 TLSは、使用するバージョンによってやりとりする流れ（シーケンス）に違いがある。現在、一般的に使われているのは、TLS 1.2とTLS 1.3である。 両者の大きな違いは、ハンドシ
Let’s Encrypt makes certs for almost 30% of web domains! RC4/3DES/TLS 1.0 are still used! Certs for hundreds of years! Analyzing hundreds of millions of SSL handshakes
Looking at a dataset of 350 million ssl connections inspires some initial questions: who made the certswhat crypto powers itwhat sort of life timeLet’s Encrypt makes certs for almost 30% of web domainsThe server you’re reading this on uses automated certs from Let’s Encrypt—they are more common on a domain than any other registrar! Over 47 million domains are protected with Let’s Encrypt certs, al
概要 SSL/TLSでは ルート証明書 (root certificate) 中間証明書 (intermediate certificate) サーバ証明書 (primary certificate) など色々なファイルや用語があり、混乱しやすいのでまとめます。 認証局(CA)について ルートCA 認証局です。 この認証局が発行するルート証明書は自身が署名します。 いわゆるオレオレ証明書になります。 一般的には社会的に信用された企業がルート認証局となります。 ブラウザなどTLSのクライアントサイドは一般的なルート証明書をデフォルトで持っています。 中間CA ルート認証局に認められた認証局です。 中間CAがあることで運用上の手続きがスムーズになったり、問題が起きた時のrevokeがしやすいといったセキュリティ的なメリットなどがあります。 詳しくは以下のサイトで説明されてます。 中間証明書の必
CloudFrontのオリジンをEC2にしてHTTPS通信を強制する構成について | DevelopersIO
余談 : HOSTヘッダ転送時のSNIホスト名について HOSTヘッダを転送した場合はオリジンアクセス時のSNIホスト名(NGINXだと$ssl_server_name)もヘッダと同じ値に設定され、パケットキャプチャの結果も確かにそうなっていました。 (HOSTヘッダを転送しない場合はSNIホスト名はオリジンドメイン名となる) 本記事の内容にはあまり関係ないとは思いますが一応記録だけ残しておきます。 試してみた ここからは簡単な検証環境を作って実際に試した結果を共有します。 検証環境は私の検証用AWSアカウントになります。 1. EC2単体でのサーバー公開 最初に東京リージョンにVPC環境とEIPを持つAmazon Linux 2023 EC2インスタンスを一台用意し、www.example.shibata.techというDNS名を与えておきます。 DNSはRoute 53を使っています。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Investigating TLS blocking in India
FirefoxがTLS1.0と1.1を再度有効化、新型コロナウイルス情報を発信する政府サイトへのアクセスを改善するため
さくらのクラウド「エンハンスドLB」を作った話(後編) - Qiita
「STARTTLS」「TLS通信」「MTA-STS」 OP25Bから始まった情報漏洩に対抗するためのメール通信経路の暗号化
GoogleがChrome独自のルート証明書プログラムを計画中 | スラド セキュリティ
【OSINT】追跡調査のチートシート | ActiveTK's Note
【図解】TLSの暗号化スイートの見方とセキュリティ設定/脆弱性の確認方法
Chain of Trust - Let's Encrypt - フリーな SSL/TLS 証明書
無料SSL証明書のLet’s Encryptとは？ | さくらのSSL
「Invoke-WebRequest」コマンドレットをTLS 1.2対応にする2つの方法
ApacheのTLS設定を2020年向けに更新する｜TechRacho by BPS株式会社
HSTS が原因で、ウェブサイトが勝手にhttps接続しないようにする
HTTP/2とTLSv1.3で、どこまで改善したか LINEのクライアントとサーバーの接続性を上げるための施策
iOS 13 および macOS 10.15 における信頼済み証明書の要件 - Apple サポート (日本)
『プロフェッショナルSSL/TLS』特別版PDF（原著改訂第2版のTLS 1.3解説章を収録）のお知らせ
走り出した TLS 1.3（２）：0-RTTでいきなり暗号化メッセージ - wolfSSL
今さら聞けない暗号技術＆認証・認可 ―Web系エンジニア必須のセキュリティ基礎力をUP
mutual-TLS(mTLS, 2way TLS)相互認証の仕組み ~クライアント認証とトークンバインディング over http
「Go 1.16.6」「Go 1.15.14」が公開 ～1件の脆弱性を修正／crypto/tlsに不正な証明書でクライアントがパニックに陥る問題
ハンドシェーク後に暗号化 TLS1.2と1.3の違いを確認
SSL/TLS周りで必要な知識 - Carpe Diem