TLS, HTTP/2演習
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
2021年 HTTPやQUICの最新動向振り返り - ASnoKaze blog
2021年について、プロトコル周りの動向を振り返っていきたいと思います。 今年は、個人的には次の2点がホットトピックと挙げられると思います。 QUICやHTTP/3を活用した応用系プロトコルの作業が進む プライバシー系の取り組みが活発化 それでは、個別に補足していきます。（IETFの動向がメインです。なお、個人的にキャッチアップできてないトピックもあります...） HTTP関連 まずは、HTTPです。HTTP/3の標準化が注目を浴びていますが、HTTP/1.1やHTTP/2なども改定作業が行われております。あわせて、HTTPセマンティクスは各バージョンから独立し、各バージョンから参照される形となりました。それぞれRFC出版の最終段階となっています。 書いた記事はここらへん HTTPのバージョンについて、現在のまとめ HTTPセマンティクス仕様の改訂版 まとめ HTTP/2の改定版仕様の変更
え! QUIC無効化するの？ HTTP over QUIC or TCPの接続選択を考える
図1: QUICの無効化は待ってくださいQUICを無効化？！“Googleが遅く感じるので、QUICを無効化する” そのようなTIPSが散見されます。数年前から見ていましたが、QUICがトレンドになったのと同時に、再び目立ち始めたと感じています。IPv6が普及し始めた時期もそうでしたが、新しいプロトコルの出現時には、決まって現れる文言です。 問題に直面する利用者にとっては切実であり、無効化は間違った解決手段とは言いません。しかしエンジニアならば無効化する前に、原因を探求しなければなりません。 HTTP3/QUIC と HTTP2/TCP どちらが優先？QUICの無効化とは、TCPだけを利用する選択と言えます。はじめにQUIC, TCPの両者が使えるとき、どのように使い分けるのか見ていきます。 ある、HTTPSスキームのURL https://www.example.com/ があったとき、
QUICをゆっくり解説(1)：QUICが標準化されました | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 不定期連載を始めます IIJ-II 技術研究所 技術開発室の山本です。私はプログラミング言語HaskellでHTTP/2とTLS 1.3を実装した後、もっぱらQUICを実装することに時間を費やしてきました。 ご存知の方もいらっしゃると思いますが、今年の5月にQUICの仕様がRFC9000として公開されました。このRFCは実によく書かれているので、読みこなせばQUICの全容が掴めるでしょう。 しかし仕様は膨大ですし、実際に実装してみて初めて腑に落ちることもあります。そこでこの機会に、実際にQUICを実装した経験者目線で、QUICの解説をしていきたいと思います。なんとなくTCP/IPを分かっている方が、ある程度QUICの理解ができることを
A Warm Welcome to ASN.1 and DER - Let's Encrypt
This document provides a gentle introduction to the data structures and formats that define the certificates used in HTTPS. It should be accessible to anyone with a little bit of computer science experience and a bit of familiarity with certificates. An HTTPS certificate is a type of file, like any other file. Its contents follow a format defined by RFC 5280. The definitions are expressed in ASN.1
DNS over TLS/HTTPSについて考える | IIJ Engineers Blog
はじめに 昨年から DNS over TLS （DoT）、DNS over HTTPS （DoH） にまつわる動きが急速に活発になっています。 DoT は2016年に RFC7858 が出てしばらくは大きな動きはありませんでしたが、2017年11月にサービス開始した public DNS である Quad9 （9.9.9.9）、昨年4月開始の Cloudflare （1.1.1.1）が相次いで DoT に正式対応し、遅れて今年1月には Google Public DNS （8.8.8.8） も対応しました。クライアント側としては昨年8月リリースの Android 9 “Pie” が DoT に対応しています。 DoH は仕様の標準化より実装の方が先行しています。Cloudflare は DoT だけでなく DoH も昨年4月のサービス開始当初からサポートしています。Mozilla Fire
HTTP and 5G (fixed1)
5GのNG-RANのOverallに関するTS、TS 38.300 V1.0.0をまとめた資料。 LTEのTS 36.300相当です。 まだ仕様未FIXでFFSのところも多いです。適宜バージョンアップしていきます。 不明点、最新の議論状況を反映できるところはできるだけ反映しました。 1 Scope 2 References 3 Abbreviations and Definitions 4 Overall Architecture and Functional Split 5 Physical Layer 6 Layer 2 7 RRC 8 NG Identities 9 Mobility and State Transitions 10 Scheduling 11 UE Power Saving 12 QoS 13 Security 14 Network Interfaces 15 Fu
Kazuho's Weblog: 次世代プロトコル（QUIC etc.）のセキュリティとプライバシー @ #builderscon
９月６日より開催中の builderscon 2018 において、登壇の機会をいただき、インターネットのトランスポート層プロトコルについてセキュリティやプライバシーに関わる設計がどのように進めてられているか、TLS と QUIC を中心に発表しました。 QUIC のハンドシェイクプロトコルとパケット番号暗号化、TLS の Encrypted SNI 拡張は、いずれも僕が提案した機能あるいは方式が採用される予定のものなので、背景にある動機や意義を含め、整理して発表する機会をもらえたことをありがたく感じています。 聴講いただいた方々、また、スライドをご覧になる方々と、次世代プロトコルの暗号応用の手法のみならず意義を含め共有し、理解と議論を深めることができれば、これに勝る喜びはありません。 PS. QUIC のハンドシェイクプロトコルと Encrypted SNI 拡張については、以下のブログ記
Go で Network Programming するためのよもやま話 / Talk for Network Programming with Go - Speaker Deck
Transcript Go Ͱ Network Programming ͢ΔͨΊ ͷΑ· Tomohiro Takezawa ࣗݾհ • ᖒ ༑ത • Github: ttakezawa • Twitter: @takezawa • גࣜձࣾKyashॴଐ • όοΫΤϯυશൠ • ಛʹ VISA QUICPay (Google Pay) ͷϓϩηγϯάγεςϜͳͲ ࣮ͱωοτϫʔΫϓϩάϥϛϯά • ࣮ࡍͷͱ͜ΖɺࣄͰ͏ػձ͋Δʁ • Kyash ͷۀͰඞਢͳͱ͜Ζ͕͋Δ • ΫϨδοτΧʔυͷϓϩηγϯάۀ • ϨΠϠʔͷཧղ͕ਂ·Δͱڧ͍ ͢͜ͱͱɺ͞ͳ͍͜ͱ • ͢͜ͱ • ιέοτϓϩάϥϛϯάશൠ • Go ʹ͓͚Δ I/O ͷΈ • ͞ͳ͍͜ͱ • HTTP • νϟωϧ ࠓͷΞδΣϯμ • ωοτϫʔΫϓϩάϥϛϯάͷجຊతͳΠϯ
RPCに特化したGoogleのセキュリティ通信ALTSとは何か - ぼちぼち日記
はじめに 昨年、Googleから Google Cloud Platform に関するWhitePaperがいくつか公開されました。その中でGoogleのサービス内部で使われている新しいALTSというプロトコルを説明した文書「Application Layer Transport Security」は、読んでみると非常に面白く、セキュアなサービス間通信には本当に何が必要なのか、といったことを改めて深く考えさせられるものでした。物理的なマシンからサービス運用まで、ALTSがカバーする範囲は幅広い領域に渡り、あの巨大なGoogleのサービスをよくここまでまとめ上げたものだとホント感心させられます。 以前から、Googleはデータセンタ内のサービス通信までも暗号化を進めていると言われていました。それは、2013年にエドワード・スノーデンが暴露した資料が、Googleのデータセンタ内部の通信データ
New attack steals SSNs, e-mail addresses, and more from HTTPS pages
Enlarge / A demo planned for Wednesday will show how an ad hosted on nytimes.com could attack other HTTPS-protected sites. The HTTPS cryptographic scheme protecting millions of websites is vulnerable to a newly revived attack that exposes encrypted e-mail addresses, social security numbers, and other sensitive data even when attackers don't have the ability to monitor a targeted end user's Interne
[PDF] HEIST: HTTP Encrypted Information can be Stolen through TCP-windows
HTTP! Encrypted! Information can be! Stolen through! TCP-windows by! Mathy Vanhoef & Tom Van Goethem HEIST Agenda • Technical background! • Same-Origin Policy! • Compression-based attacks! • SSL/TLS & TCP! • Nitty gritty HEIST details! • Demo! • Countermeasures 2 HEIST Same-Origin Policy 3 Mr. Sniffles https://bunnehbank.com GET /vault HEIST Same-Origin Policy 3 Mr. Sniffles https://bunnehbank.com
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSL/TLSとは何なんだ？ 今こそ知ってもらいたいSSL/TLSのお話 〜 1回目 〜 SSL/TLSとは | さくらのナレッジ
GitHub - aeris/firewall-piercer: SOCKS5 over TLS (over HTTPS proxy) client/server stack, providing SOCKS5 and transparent proxy client side
GitHub - artyom/tlstun: Basic socks5 over TLS proxy
TCP＋TLSに代わる高速プロトコル、Google生まれの「QUIC」の特徴と標準化の行方【IETFトピックス2016-17】
Is HEIST a Risk or a Threat?
HEIST Uses a Cryptographic Scheme to Steal Data
SSL Certificates | Web Site Security
[PDF] HEIST: HTTP Encrypted Information can be Stolen through TCP-windows