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通信
HTTP/2の仕様、改定作業が始まる - ASnoKaze blog
[追記] 2021年10月時点の変更点について新しく記事を書きました asnokaze.hatenablog.com == もくじ HTTP/2の改定作業 修正点 優先度制御について TLS1.3および0-RTT GREASEのコードポイントの予約 疑似ヘッダの扱い h2cの削除 セマンティクス仕様への参照 そのた参照の更新 security considerations の追記 HTTP/2の改定作業 HTTP/2の仕様は2015年に「RFC7540 Hypertext Transfer Protocol Version 2 (HTTP/2)」として標準化されています。 RFCは公開されたあとに、エラッタが見つかることがあります。このようなエラッタを修正するために、新しくRFCを出し直すということが行われます。 HTTP/2においてもいくつかのエラッタが公開されています (参考リンク)。
Let’s write Swift code to intercept SSL Pinning HTTPS Requests
One of the popular ways to inspect HTTPS requests in iOS Apps is the Man-in-the-middle (MITM) attack. This technique requires a machine to be used as a proxy server for the client. For this to work, the client has to install the proxy server’s certificate into the device global trust store. By doing this, the client whitelists the certificate and hence allows HTTPS communication with the proxy ser
ローカル開発環境の https 化 | blog.jxck.io
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う場
Cloudflareが1.1.1.1で超高性能DNS始めたし、いっちょ俺のパソコンもDNS over HTTPSしてみる - Qiita
Cloudflareが1.1.1.1で超高性能DNS始めたし、いっちょ俺のパソコンもDNS over HTTPSしてみる はいど〜も！バーチャルYoutuberのおのかちおです！ 先日、Cloudflareが 1.1.1.1:53 でパブリックDNSを始めたことが話題になってますよね。Googleが8.8.8.8でやってるあれと同じです。 しかもこれ、超速いんですよね。自分の手元からだと、8.8.8.8の10倍速い。 1.1.1.1の主な特徴 ログを保管しない。破棄する。 IPv6 対応 DNSSEC の対応 DNS over HTTPS の対応 DNS over SSL の対応 … IPアドレス 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001 覚えやすくていいですね。 DNS over HTTPS DNS over HT
作って学ぶ 「Https Man in The Middle Proxy」 in Go - ( ꒪⌓꒪) ゆるよろ日記
ᕕ( ᐛ )ᕗ こんにちわ、しいたけです。 webのhttps化が推進される昨今ですね? https通信は経路上での通信内容が盗聴・改竄されるのを防ぐことができますが、開発用途でhttps通信の内容を確認したい場合が稀にあります。 そのような場合は mitmproxy などを導入すればよいのですが、せっかくなので実際にこのようなProxyをGoで実装してみて、 中間者攻撃(Man-in-The-Middle Attack)がどのような手法でhttps通信を盗聴・改竄するのか確かめてみました。 実際に書いたProxyのコードはこちらです yuroyoro/mitm_proxy_sample https proxy と HTTP CONNECT tunneling まず、通常のhttps Proxyの動作を確認してみましょう。 httpsでは、ProxyはクライアントからのCONNECTメソッ
HTTP(S) Proxy in Golang in less than 100 lines of code
The goal is to implement a proxy server for HTTP and HTTPS. Handling of HTTP is a matter of parsing request, passing such request to destination server, reading response and passing it back to the client. All we need for that is built-in HTTP server and client (net/http). HTTPS is different as it’ll use technique called HTTP CONNECT tunneling. First client sends request using HTTP CONNECT method t
pixivを常時HTTPS化するまでの道のり（前編） - pixiv inside
ピクシブ株式会社で開発基盤チームとして働いている @catatsuy です。主にpixivの技術的な改善をしていますが、広告チームも兼任しているので広告周りの開発もしています。 今回pixivの常時HTTPS化を担当したのでやったことを紹介します。 pixivをHTTPS化した理由 現在のインターネット全体の流れとして常時HTTPS化が進んでいます。エドワード・スノーデン - Wikipediaが暴露したNSAの事件発覚や 公衆無線LANの利用拡大により、通信経路上でユーザーの個人情報を保護することがインターネット全体として非常に重要になってきました。Googleが行っている調査によると、HTTPSページの閲覧時間はウェブ全体の利用時間の3分の2にも及びます。 それだけではありません。ブラウザに新しく追加されるAPIや機能（HTTP2/WebRTC/ServiceWorkerなど）はHTT
kazeburo/choconと、それを支えるnet/httpの実装について
【資料公開します】AWS Dev Day Tokyo 2017 にて登壇しました／choconの簡単なご紹介 - Mercari Engineering Blog こんにちは。SREの @ kazeburo です。2017年5月31日から6月2日にAWS Summit Tokyo 2017と同時に開催された「AWS Dev Day Tokyo 2017」に登壇しました。 登壇する機会をいただき、ま… 先日、というか昨日、この資料が流れてきまして、Private Networkの外部との通信を効率良く行うためのミドルウェア、choconというproxyサーバーが紹介されていました。SSL, HTTP/2を加味した上での超シンプルで高速なforward proxyサーバー実装という印象です。 使い方やAPIの叩き方は上記のリンクを参考にしていただくとして、やたらマイクロな実装でなぜこうも高速に
ngx_mrubyで最初のHTTPSアクセス時に自動で証明書を設定可能にするFastCertificateの提案とPoC - 人間とウェブの未来
Let’s EncryptやACMEプロトコルによるDV証明書取得の自動化に伴い、証明書の取得と設定が簡単になってきました。 一方で、ACMEをツール化したものが増えるに従って、ACMEってそもそもどういう動きになっているのか、とか、自分たちの用途でどういう使い方がありえるのかとかが余計にわかりにくくなってきており、どこまで自動化できるかもよくわからない場合が多いのではないでしょうか。 そこで、 ドメインとAレコードの紐付けさえしていれば、最初のアクセス時に自動で証明書をとってきて、HTTPS通信にできないか というような、いわゆる FastCertificate 的な動きを実現したいと考え、ACMEの通信の中で各種処理を別のスクリプトでhookできるdehydratedとngx_mrubyを応用して実現可否も含めてPoCを実装してみました。 ※ FastContainerという考え方につ
Node.js + Express で HTTPS サーバー を 作る
Node.js + Express の環境で HTTPS 通信できるようにする方法を整理しました。 あまり複雑な要素は含めずできるだけシンプルなサンプルコードを掲載します。 HTTPS サーバー 構築 Windows の IIS で自己署名入り証明書 をエクスポートすると PKCS#12 の証明書 (拡張子 pfx のファイル) になっているので、 今回は pfx を指定してHTTPSサーバーを構築してみます。 IIS で 自己署名入り証明書 を作成、エクスポートする方法は以下の「自己署名証明書の作成」を参照してください。 var express = require("express"); var fs = require("fs"); var https = require("https"); var app = express(); var options = { pfx: fs.re
Rundeckの前段にnginxを配置してhttps化する - Qiita
はじめに RundeckはデフォルトだとWebの管理画面はhttpなんだけど、まともに使うならhttps化しておきたい。 いちおう、Rundeck単体でもSSLの設定することは可能っぽいんだけど、 http://rundeck.org/docs/administration/configuring-ssl.html 見るからにちょっと、めんどくさそうで、Rundeck初心者には敷居が高そうである。 ところで、Rundeckの前段にnginxを配置してhttps化する構成なら大体nginxの知識+αでなんとかなりそうなので、nginxでSSL復号化する構成にしてみる。 RundeckのSSL復号化をnginxにオフロードする 前段のnginxでSSL復号化する構成については、公式wikiに以下のような簡単な説明があるんだけど、 https://github.com/rundeck/runde
CloudflareでGitHub PagesをHTTPS化
B! 13 0 0 0 独自ドメインにしたついでに GitHub Pagesを使ってる人がよくやってるCloudflareというCDNサービスを 使ったHTTPS化をやってみました。 HTTPS化は時代の流れ的な所を受けて、 ということもありますが、取り敢えずCloudflareとか使ってみたかったので。 Cloudflare GitHub Pages + Cloudflare Cloudflareでドメインを登録 ドメインサービス側での設定 Cloudflareでの設定 Ctyptタブ Page Rulesタブ Speedタブ 変更後 Cloudflare Cloudflare はCDN(Content Delivery Network)サービスを含むネットワークサービスを提供しているサービスです。 2017年1月の時点で全ウェブサイトの5.3%もがCloudflare経由で供給されてる
「HTTPプロクシライブラリproxy2の設計と実装」というタイトルで発表した - ももいろテクノロジー
プレゼンテーション：HTTPプロクシライブラリproxy2の設計と実装 | PyCon JP 2016 in TOKYO PyCon JP 2016で以前作ったPython製HTTPプロクシライブラリについて発表した。 HTTPプロクシライブラリproxy2の設計と実装 from inaz2 きちんとPython 3対応にした状態で発表できなかったのが少し心残りではあるが、以前の発表であまり触れられなかった実装面のあれこれについてまとめることができてよかった。 また、Accept-Encodingの扱いが雑で、うまくいかないケースが出てきていることに気づけたという点でも、よい機会だった。 スタッフ、参加者の方とも交流することができ、楽しいイベントでした。 PyCon JPスタッフのみなさま、ありがとうございました。
Google Public DNS over HTTPS を試す | IIJ Engineers Blog
【2018/11/16 追記】 本記事は、2016 年 4 月に Google Public DNS サーバに実装された、実験的な DNS over HTTPS プロトコルについて紹介しています。DNS over HTTPS プロトコルはその後 IETF の doh ワーキンググループにて標準化が進められ、2年半後の 2018 年 10 月に RFC8484 として出版されました。本記事で紹介したプロトコルは RFC8484 に規定されたプロトコルとはいくつもの点で異なっていることにご注意ください。 Google Inc. が公開 DNS サーバを運営していることはご存知でしょうか? Google Public DNS と呼ばれるこの公開 DNS サーバは、”8.8.8.8″ という特徴的な IP アドレスで全世界のインターネットユーザに対して無料の DNS サーバ(フルレゾルバ)を提供し
tcpdump + wireshark で https な通信を解読する - Qiita
webアプリケーション開発者たるもの、時には https と戦わねばならぬこともあるのです。 打つ手がなくて泣きそうになっていたら同僚から救いの手が！ (ただしサーバ側/クライアント側のいずれかで鍵交換アルゴリズムを変更できる場合に限る) まず、tcpdump でダンプしたものを wireshark で見るには -w FILE オプションをつけてダンプデータをファイルに書き出させます。環境によってはデフォルトで先頭数十バイトしかダンプしない (man によれば、CentOS 5.x で 68 bytes, 同じく Ubuntu 10.04 で 65535 bytes)ようなので、-s 65535 とか -s 0 などとダンプさせるサイズを指定してやるのが吉 今回は https なのでお手軽にポートで絞ることにして...こんな感じで叩けば良いかと。 出力されたファイルは普通に wiresha
HTTPSにまつわる怪しい伝説を検証する - Google I/O 2016のセッションから - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 今年はGoogle I/Oに初めて社員ではない立場で参加しました。全体の感想は Google I/O 2016まとめ（Web的視点） で公開していますが、今回はその中で、気に入ったセッションの1つである"Mythbusting HTTPS: Squashing security’s urban legends"について書いてみたいと思います。 セッションは大変良くまとまっていますので、YouTubeにあがっている動画を見れる人は動画を見て貰えれば良いのですが、時間が無いという人のために、その内容をまとめました。基本的には文字起こしに近い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【図解】https(SSL/TLS)の仕組みとシーケンス,パケット構造 〜暗号化の範囲, Encrypted Alert, ヘッダやレイヤについて～
GitHub - SteveLTN/https-portal: A fully automated HTTPS server powered by Nginx, Let's Encrypt and Docker.
cookpad.com 全 HTTPS 化の軌跡
