[B! TLS] igrepのブックマーク

サーバー間通信の暗号化を Tailscale に丸投げする

まとめ Erlang/OTP の分散機能利用時のサーバー間通信はデフォルトでは暗号化されていない Erlang/OTP が提供する分散機能の暗号化は TLS を利用する Tailscale で P2P VPN をサーバー間で張って Erlang/OTP の分散機能オススメ Erlang 分散機能時雨堂で開発しているミドルウェアソフトウェアは Erlang/OTP (以下 Erlang) を利用しています。 Erlang は分散機能が入っています。分散機能を簡単に説明すると、他のサーバーにある Erlang とやりとりができる仕組みです。このときにサーバ間を利用する際に、暗号化が必要になりますが、Erlang が標準で提供為てる機能はサーバー間通信を TLS にする方法がありますが、Erlang に TLS 処理させるのは CPU も食べるしお勧めはできません。 Erlang -- Us

igrep 2023/01/11

リンク

HTTP/2を利用する際はCipher Suiteを正しく設定しよう | IIJ Engineers Blog

2018年新卒入社。名古屋支社にてSI中心にお仕事をするエンジニア。仕事ではサーバやミドルウェアを、趣味ではウェブやアプリを弄っています。︻IIJ 2021 TECHアドベントカレンダー 12/9︵木︶の記事です︼はじめに名古屋支社のkmmt-t です。最近のモダンなWebサイトでは、﹁HTTP/2﹂を利用するサイトが増えてきました。このようなWebサイトを公開する際に、Webサーバ側の設定次第によってはモダンブラウザ︵EdgeやChrome︶でページを開けない場合があります。具体的にはTLS1.2とHTTP/2を組み合わせたWebサイトにおいて、特定のCipher Suiteを指定している場合にブラウザが ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY 等のエラーを出してページをブロックするような現象が発生します。特に、利用者側がインターネ

igrep 2021/12/09

リンク

Private Relay と IP Blindness による Fingerprint 対策 | blog.jxck.io

Intro iOS15 がリリースされたため、 Private Relay のベータを試すことができた。このようなサービスが提供されるようになった背景を踏まえ、挙動を簡単に確認しつつ、解説する。背景そもそも、なぜこのようなサービスが出てきたのかを理解するには、現在のインターネットが抱える問題の背景を理解する必要がある。特に Web において問題になっている﹁トラッキング﹂を防ぐために、法的な規制や業界団体の自主規制による対策は長いこと行われてきたが、それでも看過できないインシデントなどが目立ったために、 Apple の ITPを皮切りに 3rd Party Cookie の制限が始まった。ここで重要なのは、﹁本来防ぎたいのは 3rd party Cookie という技術ではなく Tracking というユースケースだ﹂という点だ。この前提が伝わっていない場合、トラッキングのユ

igrep 2021/09/23

リンク

Application-Layer Protocol Negotiation - Wikipedia

Application-Layer Protocol Negotiation (ALPN) は、Transport Layer Security (TLS) の拡張の一つである。アプリケーション層でのプロトコルネゴシエーションに関する拡張であり、セキュア通信においてアプリケーション層がどの通信プロトコルを使用するのかを決定する際に、余分なラウンドトリップタイムの発生を避け、アプリケーション層のプロトコルに依らずにネゴシエーションを行うことを可能とする。ALPNは主にSPDYおよびHTTP/2で利用されている。 2021年現在では、ALPACAと命名されたTLSにおけるクロスプロトコル攻撃の対策の1つとして、それ以外のアプリケーションプロトコルでもALPNの利用が推奨されている[1]。標準仕様[編集] 2014年7月11日、ALPNの仕様はRFC 7301にてProposed standa

igrep 2021/07/01

TLS
http

リンク

図解 X.509 証明書 - Qiita

はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名（前提知識）この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと

igrep 2020/07/17

ありがたや

リンク

FirefoxがTLS1.0と1.1を再度有効化、新型コロナウイルス情報を発信する政府サイトへのアクセスを改善するため

「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.

igrep 2020/03/27

つらい

リンク

IIJのDNS暗号化への取り組み | IIJ Engineers Blog

はじめにネットワーククラウド本部の其田です。今回はIIJのDNS暗号化への取り組みを紹介します。この記事で紹介するのは、本日プレスリリースした﹁IIJ、接続サービスで提供するDNSのセキュリティを強化﹂の中の、DNSキャッシュサーバとお客様の間の通信(DoT/DoH)に該当します。取り組みのきっかけ IIJでのDNS暗号化の取り組みは2018年からスタートしています。当時本命とされたDNS over TLS(DoT)は2016年にRFC化されているので、ちょっと遅いスタートだったかもしれません。DoTやDoH(DNS over HTTPS)が対象とする、フルリゾルバ(DNSキャッシュサーバ)～スタブリゾルバ(パソコンやスマホの中に組み込まれているDNS問い合わせ機能)の間の通信は、ISPの契約者がISPが用意したDNSキャッシュサーバを使う限りはインターネットを通過せず、特定のIS

igrep 2020/01/17

リンク

Bringing TLS 1.3 to Haskell - あどけない話

Haskell TLS library version 1.4.1 or earlier support SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. Here is brief summary of their security: SSL 2.0 is insecure and obsoleted by RFC 6176 SSL 3.0 is insecure and obsoleted by RFC 7568 TLS 1.0 is insecure due to lack of AEAD TLS 1.1 is insecure due to lack of AEAD TLS 1.2 is secure if it is used with proper parameters (using (EC)DHE and AEAD, disabl

igrep 2019/06/08

]“ both TLS 1.0 and TLS 1.1 are vulnerable. Actually, HTTP/2 requires TLS 1.2 with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or stronger. Also, major browsers are planning to disable TLS 1.0 and 1.1 in 2020.” セキュアにするの難しい...

TLS
Security

リンク

Encrypted SNI / TLSハンドシェイクの暗号化 - Qiita

SNI とは一つのIPアドレスと一つのTCPポートで、複数のWebサイトをホスティングする技術の一つに、virtualhostがあります。これは、HTTPリクエスト内で指定するドメイン名から、同じIPに対するアクセスをドメインごとに振り分ける機能です。たとえば、以下のコマンドを実行すると、こんな出力がされます。（ちなみに、vがリクエストヘッダの表示、 Iがボディの非表示のオプションです。） $ curl -v -I example.com * Trying xxxxx... * TCP_NODELAY set * Connected to example.com (xxxxx) port 80 (#0) > HEAD / HTTP/1.1 > Host: example.com > User-Agent: curl/7.62.0 > Accept: */* > …（省略）真ん中の

igrep 2019/02/13

Security
tls

リンク

TLS 1.3 開発日記その28 RFC8446 - あどけない話

はてなダイアリーからはてなブログに移行しました。今後も、細々とブログを書いていきます。 2018年8月、TLS 1.3がRFC8446になりました！(TLSのRFCは、伝統的にXX46という番号になります。) RFC8446の貢献者リストに僕の名前が載っていることを聞きつけたIIJ広報から依頼されたので、TLS 1.3の標準化と実装というブログ記事を書きました。執筆中にはリリースされていませんでしたが、現在ではTLS 1.3 対応済みの Firefox 63 と Chrome70が、めでたくリリースされています。 RFC8446の策定後、Haskell の tls ライブラリも、他の実装と相互接続性を確認しました。また、私の実装がtls ライブラリの本家にマージされました。Haskell tls ライブラリをリリースするには、鍵のアップデートダウングレード対策クライアント認証を

igrep 2018/10/30

tls
iij

リンク

TLS 1.3の標準化と実装 | IIJ Engineers Blog

IIJ-II 技術研究所技術開発室の山本です。現在技術開発室は、私を含めた4人で構成されており、主にプログラミング言語Haskellを使って開発を進めています。今回の話題である TLS(Transport Layer Security) 1.3 もHaskellで実装しました。4年の歳月をかけて議論されてきたTLS 1.3ですが、この8月にめでたく仕様がRFC 8446となりました。貢献者リストに私の名前が載っていることを聞きつけた広報から、ブログ記事の執筆依頼がありましたので、TLS 1.3の標準化や実装の話について書いてみます。なぜTLS 1.3を標準化する必要があったのか理由を知りたい方は、﹁TLSの動向﹂という記事や﹁TLS 1.3﹂というスライドを読んで下さい。インターネットで使われているプロトコルは、IETFという団体で仕様が議論されて策定されます。IETFには、誰でも

igrep 2018/09/25

kazuさんがTLS 1.3の策定に関わった話！

リンク

今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景

︻変更履歴 2018年2月15日︼当初の記事タイトルは﹁いまなぜHTTPS化なのか？技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景﹂でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途

igrep 2018/04/09

リンク

TLS 1.3 開発日記その22 公開鍵暗号の動向 - あどけない話

P256とかX25519とかPSSとか聞いても、よくわからない人のための用語解説。長い間TLSの世界では、鍵交換にも認証にもRSAが使われてきた。必要となる安全性が大きくなると、RSAの公開鍵は急激に大きくなり、したがって鍵交換や認証のコストが大きくなるという問題がある。楕円曲線暗号(ECC: Elliptic Curve Cryptography)は、RSAやDiffie Hellmanに比べると、小さな公開鍵で同程度の安全性を実現するという特長を持つ。特許問題が不透明なせいで楕円曲線暗号は長年敬遠されてきたが、この数年で(少なくとも鍵交換に対しては)一気に普及してきた感じだ。おおざっぱに言うと、楕円曲線暗号で実現できるのは、DH(Diffie Hellman)とDSA(Digital Signature Algorithm)であり、RSAは実現できない。鍵交換のDHに関しては、

igrep 2017/11/22

リンク

TLS 1.3 開発日記その21 TLS 1.3 ID22 - あどけない話

TLS 1.3 ID21までの仕様は、 ServerHelloの書式がTLS 1.2と異なる ChangeCipherSpecがないという特徴があった。 ServerHelloが異なるということは、TLS 1.3に非対応であったWiresharkで表示できなくて辛いとか、パーサーの中で分岐しなければならないので関数プログラミングの考えでコードが書きにくいなどの問題があった。その後、はやり世の中にはTLS 1.3を遮断するミドルボックスが少数ながらも存在することが分かり、これらのミドルボックスを騙すための方法が考案された。現在 PR1091 で議論中だが、開発者の間ではこのPRをマージした版がID22とすることで合意が取れている。その方法とはこうだ‥ ServerHelloの書式をTLS 1.2と同じにするバージョンはTLS 1.2を指定する圧縮方式が復活。常に0 セッションIDが復

igrep 2017/11/14

tls

リンク

TLS 1.3 開発日記その8 開発メモ - あどけない話

これは、http2 Advent Calendar 2016の25日目の記事です。この記事では、HaskellでTLS 1.3を開発した際に難しかった点をまとめます。自分のための覚書です。TLS 1.3のみをフルスクラッチで書くと、そこまで難しくないのかもしれませんが、TLS 1.2以前と共存させるのは大変です。足らない部品 TLS 1.2のコードが存在しても、TLS 1.3では TLS 1.2で利用されてない部品が必要です‥ RSA PSS PSS は PKCS#1 は異なるパディング方式の署名。RSAの公開鍵/秘密鍵自体は流用できる HKDF X25519 と X448 これらは、Haskell の cryptoniteにすべて揃っていたので、少し(かなり？)手を入れるだけで利用できるようになりました。拡張の再利用 TLS 1.3では、TLS 1.2 の2つの拡張を再利用してい

igrep 2016/12/28

"将来知らない値が来たときに試すのではなく、いつも知らない値を送ることで、パーサをテストし続けるというのが Applying GREASE to TLS Extensibility"

Haskell
TLS

リンク

wreqでSSL通信が遅い場合の対処法 - Qiita

wreq はデフォルトで http-client-tls を使ってSSL通信するのだけど、これが結構遅くてビビった1。そこで、 tls パッケージではなく OpenSSL の Haskell バインディングである HsOpenSSL に差し替えてみたら、手元で 40 秒かかっていたバッチの実行時間が 30 秒まで短くなった。 25% の改善。差し替えるには、 HsOpenSSL パッケージと http-client-openssl パッケージへの依存を *.cabal へ追加して、 import qualified Network.Wreq as Wreq main :: IO () main = do res <- Wreq.get uri ... import Control.Lens ((&), (.~)) import qualified Network.HTTP.Client

igrep 2016/12/25

おお、差し替えることを想定して作られているんだ。

haskell
TLS

リンク

TLS 1.3 開発日記その3 バージョン - あどけない話

これは、http2 Advent Calendar 2016の7日目の記事です。今回はTLSのバージョンについて書きます。TLSのバージョンは、Client Hello と Server Hello を交換することで決めます。 Client Hello TLS 1.3 の Client Hello は、TLS 1.2 と互換性を維持するために、構造が死守されています。 TLS 1.2 の Client Hello の定義はこう‥ struct { ProtocolVersion client_version; Random random; SessionIDsession_id; CipherSuite cipher_suites<2..2^16-2>; CompressionMethod compression_methods<1..2^8-1>; select (extension

igrep 2016/12/09

“ある1つの値を2つの場所で指示しているなら、それはバグです”データ構造もDRYにしなきゃね。

リンク

TLS 1.3 開発日記その1 実装状況 - あどけない話

これは、http2 Advent Calendar 2016の1日目の記事です。現在、IETF で TLS 1.3 の標準化が大詰めを迎えています。僕も TLS 1.3 の標準化に参加しており、仕様の分かりにくい部分を直したり、TLS 1.3 を Haskell で実装したりしています。この開発日記のシリーズでは、TLS 1.3の仕組みを説明していこうと思います。そもそも、なぜ TLS 1.3 が必要なのかは、TLSの動向をお読み下さい。なお、次のTLSのバージョンを何にするかは、現在もめていて、1.3ではなくなる可能性もあることに注意して下さい。現在の実装現在利用できる TLS 1.3 の実装の一覧は、Implementationsにまとまっています。僕がクライアントとしてよく使っているのは、Firefox Nightly、Chrome Canary、および picotls です

igrep 2016/12/02

リンク

HTTP Strict Transport Security(HSTS) 対応 | blog.jxck.io

Intro 本サイトにて HTTP Strict Transport Security (HSTS) を有効化した。 includeSubdomainsを用いた *.jxck.io 全体への適用および、ブラウザへの Preload 登録も検討したが、本サイトの特性上それは見送った。導入に必要な設定や、注意点についてまとめる。 HSTS 本サイト (blog.jxck.io) では、フル HTTPS 化が完了しており、 HTTP へのリクエストは全て HTTPS へリダイレクトしている。特に本サイトのタイトル自体が blog.jxck.io であり、ドメイン名と同じになっているため、これが Twitter などで http://blog.jxck.io へのリンクと解釈される場合が多く、そこからの HTTP アクセスも少なくはない。しかし、MITMの脅威への対策が可能な HTTP

igrep 2016/04/12

"httpのリンクを踏んでも、ブラウザが自動的にhttpsに置き換えてアクセスさせる仕組みが HSTS"

リンク

セキュリティ診断・検査のGMOサイバーセキュリティ byイエラエ

GMOサイバーセキュリティ byイエラエ株式会社は国内トップクラスのホワイトハッカーが多数在籍するサイバーセキュリティの会社です。攻撃手法に関する豊富な知識と最先端の技術を持つホワイトハッカーが仮想敵となり、お客様の抱えるセキュリティ上の問題の可視化と課題解決をサポートします。「誰もが犠牲にならない社会を創る」をミッションとして掲げ、デジタルネイティブの時代を生きるすべての人が安全に暮らせるインターネット社会創りに貢献します。

igrep 2015/12/07

リンク

はてなブックマーク

タグ

関連タグで絞り込む (24)

TLSに関するigrepのブックマーク (24)

お知らせ

今週のはてなブックマーク数ランキング（2024年6月第4週）

今週のはてなブックマーク数ランキング（2024年6月第3週）

今週のはてなブックマーク数ランキング（2024年6月第2週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス