DNS over TLS - Thoughts and Implementation
Discussion on Hacker News. A week or so I discovered that Android P has DNS over TLS support! It piqued my curiousity - could it finally be that DNS encryption goes mainstream? In this post we’ll survey DNS over TLS, implement a client and share some thoughts! Party like it's 1983 TL;DR Sure, with DNS over TLS your DNS queries are encrypted - that’s a major step forward! Nevertheless, the majority
「SSL/TLS暗号設定ガイドライン改訂及び鍵管理ガイドライン作成のための調査・検討」報告書 | アーカイブ | IPA 独立行政法人 情報処理推進機構
本ページの情報は2018年6月時点のものです。 独立行政法人情報処理推進機構（以下「IPA」という。）では、近年の情報セキュリティの基盤技術として広く利用されている暗号について、暗号技術評価プロジェクトCRYPTRECの活動を通じ、SSL (Secure Sockets Layer) / TLS (Transport Layer Security) の適切な利用促進を目的として、SSL/TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするための「SSL/TLS暗号設定ガイドライン」を2015年5月に公開しました。その公開から約3年が経過し、SSL/TLSを取り巻く状況の変化やSSL/TLSをサポートするアプリケーションのバージョンアップ等を反映した内容とするための改訂が必要となってきました。 また、2016年度のCRYPTREC活動において、暗号を正しく使う
QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
先週スウェーデンのKistaで開催された第５回QUIC Interimで、ハンドシェイクプロトコルの再設計案の採用が決まりました。 提案者として、その背景にある考え方を整理したいと思います。 ▪️提案内容 詳しくはDesign Docを見てもらえばいいとして、ざっくりいうと、TLSスタックをふたつに分割し パケットはQUICがレイアウトしたバイト列をTLSスタックが提供するAPIを使って暗号化注1して生成 ハンドシェイクメッセージについては、平文のメッセージをTLSスタックとQUICスタックとの間で交換し、QUICスタック側で上記手法によるパケット化暗号化を行う というものです。 これにより、たとえばサーバがハンドシェイク時に送出するパケットの構造は以下のようにかわります。 図1. 従来方式 図2. 新方式 赤は難読化（つまり正当なパケットと攻撃との区別がつかない）、黄は未認証の暗号化（通
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか？ 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途
SSL/TLSについてまとめ2018 - Qiita
はじめに SSL/TLSについて改めて理解を深めたい思い、関連する技術についてまとめました。 本記事はTLSに関すること主題として、HTTPS、暗号化、Apache、OpenSSL等について記載しています。 SSL/TLSの通信は色々なプロトコルや暗号化方式が組み合わされ補いあってできています。暗号化の仕組みはパズルのようで面白いです。一つ一つを読み取り理解が深まるごとで、SSL/TLSって本当によくできると思いました。フレームワークの意味について考えさられます。 HTTPSの通信 HTTPSの通信はTCP/IPプロトコルスイートとして、TCPの上層にSSL/TLSがあり、アプリケーションプロトコルのHTTPプロトコルが載って通信をしています。 コネクションとセッションは通信の概念として別になります。TCPでクライアントからWebサーバに対してコネクション(経路)が確立され、その上でセッシ
httpsって知っていますか？今さら聞けない基礎知識
”http://”と”https://”の違いを明確に答えられますか？そもそも、違いを意識したことはありますか？ 見たことはあるような気がするけど説明するのは難しいな、という方も多いのではないでしょうか。 ここでは、HTTPSの基礎知識を簡単に説明します。 HTTP、HTTPSはデータをやり取りするための世界共通のルール さて、そもそも”http://”や”https://”とはなんなのでしょうか。 ものすごく簡単にいうと、「ホームページを表示するための世界共通のルール」です。 「ホームページを見るときに、アドレス(URL)の最初に必ず付けないといけないもの」くらいの認識の方もいらっしゃるかもしれませんね。 それはそれであっています。 ホームページを閲覧する上では欠かせないルール（約束事）なのです。 少しだけ技術的(？)に説明するなら、ホームページのデータはサーバー上に保管されています。ホ
プロフェッショナルSSL/TLS
こちらは改訂前の旧版のページです。改題第2版の商品ページをご覧ください Webセキュリティ解説の決定版 "Bulletproof SSL and TLS" の全訳（原書2017年版へのアップグレード済み） Ivan Ristić 著、齋藤孝道 監訳 520ページ B5判 ISBN：978-4-908686-00-9 電子書籍の形式：PDF 2020年7月4日 第1版第5刷 発行（原書2017年版アップグレード対応済み） 本サイトにてユーザ登録のうえ購入いただくと、原著改訂第2版に収録されるTLS 1.3の解説章を付録として含んだ特別版PDFがお読みいただけます 現代生活を支えるネットワークにとって、通信の暗号化は不可欠の機能です。しかし、実際のインターネットで暗号化通信を利用できるようにするには、暗号化アルゴリズムの知識だけでなく、セキュリティプロトコルとその実装技術、さらに、基盤となる信
POODLE（プードル）攻撃ってどんな攻撃？
サイバーセキュリティ分野における初の国家資格「情報処理安全確保支援士」制度が始まりました。資格試験の受験を検討している人も、そうでない人も過去問題にチャレンジしてみましょう。今回は、「POODLE（プードル）攻撃」についての問題です。 ア SSL 3.0のサーバプログラムの脆ぜい弱性を突く攻撃であり、サーバのメモリに不正アクセスして秘密鍵を窃取できる。 イ SSL 3.0を使用した通信において、ブロック暗号のCBCモード利用時の脆弱性を突く攻撃であり、パディングを悪用して暗号化通信の内容を解読できる。 ウ TLS 1.2のプロトコル仕様の脆弱性を突く攻撃であり、TLSの旧バージョンにダウングレードして暗号化通信の内容を解読できる。 エ TLS 1.2を使用した通信において、Diffie-Hellman鍵交換アルゴリズムの脆弱性を突く攻撃であり、交換されたセッション鍵を窃取して暗号化通信の内
AWS Solutions Architect ブログ
Amazon Web Servicesでは強力な暗号化は標準機能の一つであり、（以前はSSLとよばれた）TLSという暗号化プロトコルが必要不可欠です。 TLSは全てのAWS APIで用いられており、Elastic Load Balancing (ELB), AWS Elastic Beanstalk, Amazon CloudFront, Amazon S3, Amazon RDS, Amazon SESなどのお客様が直接使うサービスでも使われています。 過去18ヶ月程の間は、TLSプロトコルの波乱に満ちた期間でした。優れた暗号解析技術はこれまで考えられていたよりも深刻であるいくつかのTLSアルゴリズムの欠陥をハイライトし、セキュリティ研究はTLSのいくつかのソフトウェア実装に問題を明らかにしました。総体としてはこれらの開発は正しくセキュリティを向上させるものでしたが、ソフトウェアアップグ
錆びついたTLSを滑らかに、GoogleによるGREASE試験 - ぼちぼち日記
0. 短いまとめ 長い間、TLSのクライアント・サーバ間で使用するTLSバージョンを合意する際に、 不完全なサーバ実装によって version intolerance が発生することが問題になっていました。 TLS1.3ではこの version intolerance の影響を最小化するため、新しい version negotiation の仕組みを取り入れました。 Googleは、GREASE(Generate Random Extensions And Sustain Extensibility)という仕様をChromeに実装し、TLSサーバのバグで通らない拡張やフィールド値で問題が発生しないか試験を始めました。 パケットキャプチャが好きな人は、Chromeが 0x[0-f]a0x[0-f]a の見慣れない値をCipherSuiteやTLS拡張に使っているのを見つけても驚かないよう気を
エンジニアなら知っておきたい、絵で見てわかるセキュア通信の基本 - Qiita
TLS 1.3は現在策定中ですが、 前方秘匿性 の問題から RSAのみ を用いた鍵委共有が禁止になる見込みです。(詳細は後述します) HTTPSとは 次に、HTTPSです。 HTTPS - Wikipedia HTTPS（Hypertext Transfer Protocol Secure）は、HTTPによる通信を安全に（セキュアに）行うためのプロトコルおよびURIスキームである。 厳密に言えば、HTTPS自体はプロトコルではなく、SSL/TLSプロトコルによって提供される セキュアな接続の上でHTTP通信を行うこと をHTTPSと呼んでいる。 とのことです。 HTTPの説明を割愛するとすれば、「SSL/TLSでセキュアにHTTPをやる」というだけの説明で済んでしまいます。 最近では個人情報等の観点から全てのサイトをHTTPSにするような動きが見られますが、元々HTTPSが使われやすかった
TLS のひみつ : 迷惑メール対策委員会
IIJ 技術研究所 山本和彦 2008年2月 1.SSL 2.TLS 3.ラッパーとしての TLS 4.蛇足 SSL（Secure Socket Layer）はラッパー（トンネル）として実装できるが、TLS（Transport Layer Security）はラッパーとして実装できないと勘違いしているエンジニアが多い。この記事では、（少なくともクライアント側では）TLS がラッパーとして実装でき、アプリケーションプログラムの実装を変更しなくても TLS が利用できることを示す。 1. SSL あるアプリケーションサービスを SSL を用いて保護するときは、別途ポートを用意しなければならない。たとえば、HTTP（80）を SSL で守るために、HTTPS（443）が定義されている。 このポートの分離のおかげで、HTTPS を見張るプログラムは通信がはじめから暗号文であると決め打ちできる。同様
TLS1.3とは何か？
プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの / Streamlining Product Validation in Growth Phase
セキュリティ診断・検査のGMOサイバーセキュリティ byイエラエ
『OffSec Training』の対象コースが世界最安となる早割+10%OFFキャンペーン中です。 脆弱性診断やペネトレーションテストのエキスパートを目指す方へ絶好のチャンスです！ 詳細はこちら
理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 · けんごのお屋敷
apache や nginx の設定をしたことがあれば以下の様な行を見たことがある人も多いのではないでしょうか。(※ 下記は nginx の設定。apache の場合は SSLCipherSuite です。) ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; これが暗号スイートを指定している箇所です。そしてこの部分、わけのわからない文字列の羅列なのですごく取っつきにくくて何を指定したらいいかわからないので、コピペしてしまう人も多いんじゃないでしょうか。かくいう私も数年前に趣味で TLS 対応の Web サービスを作った時はコピペで済ませていました。この暗号スイートは、以下のような OpenSSL のコマンドを使って対応している一覧を見ることができます。 $ openssl ciphers -v AES128-SH
qpstudy 2015.11.14 一歩先を行くインフラエンジニアに知ってほしいSSL/TLS
インフラエンジニアの方向けに、SSL/TLSとは何か、また証明書入手のポイント、HTTPS設定のポイントについて、最新の動向を踏まえて紹介します。また、最後の方で勉強会主催者のリクエストでおまけがあります(^^;Read less
TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
組込用SSL/TLS「MatrixSSL」に複数の脆弱性、アップデートを呼びかけ（JVN） | ScanNetSecurity
TLS徹底演習