社内勉強会で専門的技術力を高めるには
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog サイトオペレーション本部に所属している大津と申します。普段CDNとNode.jsサポートの仕事をしていて、第9代黒帯（ヤフー内のスキル任命制度／ネットワーク・セキュリティ）に任命していただいています。1 先日ヤフー社内で黒帯LT会が開催されました。お題目は事前に指定された「専門的技術力を極めるための極意」ということで、10分ほど話をしました。しかし、これまでみたいにセミナールームで大勢の前で話すわけではなく、最近代わり映えしない自宅デスクからのオンラインLTは、正直勝手が違いました。時間配分もミスって中途半端に終了です。と思いきや数日前、このYahoo! JAPAN Tech Blog担当者から「いやー、よかったですよ。そのネタ書
一見不可解な TLS 証明書失効
この記事は、所属する会社の社内ブログに投稿した内容を一部改変したものです。 遭遇した事象 Prometheus と https://github.com/prometheus/blackbox_exporter を使って TLS サーバー証明書の有効性と有効期限を網羅的に監視しています。最近 blackbox_exporter が blog.cookpad.dk:443 の証明書の期限が切れている、と報告してきました。しかし同時に blackbox_exporter は TLS 接続には成功している、と報告していたのです。確認のため、Chrome で https://blog.cookpad.dk/ にアクセスしてみると、問題ありませんでした。Firefox でも同様でした。次に手元の MacBook Pro から cURL してみます。 $ curl -v https://blog.co
InfoQ: HTTPSコネクションの最初の数ミリ秒
ほとんどの人がHTTPSとSSL (Secure Sockets Layer) を結びつけて考えます。SSLは1990年代半ばにNetscape社が開発した仕組みですが、今ではこの事実はあまり正確でないかもしれません。Netscape社が市場のシェアを失うにしたがって、SSLのメンテナンスはインターネット技術タスクフォース(IETF)へ移管されました。Netscape社から移管されて以降の初めてバージョンはTransport Layer Security (TLS)1.0と名付けられ、1999年1月にリリースされました。TLSが使われだして10年も経っているので、純粋な"SSL"のトラフィックを見ることはほとんどありません。 Client Hello TLSはすべてのトラフィックを異なるタイプの"レコード"で包みます。ブラウザが出す先頭のバイト値は16進数表記で0x16 = 22。 これは
「SSL/TLS暗号設定ガイドライン 第2.0版」を読んで - ぼちぼち日記
1. はじめに 昨日「SSL/TLS暗号設定ガイドライン 第2.0版」が公開されました。 前回から約3年経って今回はCRYPTREC暗号技術活用委員会で検討作業が行われたようです。 普段、TLS/HTTPSの記事を書いたり発表したりしている立場上、これを見逃すわけにはいけません。 本文冒頭では、 「本ガイドラインは、2018 年 3 月時点における、SSL/TLS 通信での安全性と可用性（相互接続性）のバランスを踏まえた SSL/TLS サーバの設定方法を示すものである。」 ということなので、できたてほっかほっかの最新ガイドラインを読ませていただきました。 読み進めてみるとChangelogが細かく書いてなく、以前のバージョンとどこがどう変わったのかよくわかりません。TLS1.3とかは絶対に新しく入った内容なんですが、細かいところはどうだろう… それでも全部(SSL-VPNを除く)をざっと
SSL/TLSの基礎と最新動向
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
DH鍵交換でもWiresharkでSSL/TLSを復号化したい - 逆さまにした
WiresharkでSSL通信の中身を覗いてみる を拝見し、実際に自分の手を動かしてみたのですが、記事内でも触れられているようにDiffie-Hellman(DH) key exchange (および楕円曲線を用いたECDH) では、実際に鍵を送り合うわけではなく、鍵を生成するためのパラメータだけがやり取りされるので、サーバの秘密鍵を持っていても復号できません。 今回はDH鍵交換(以下、DHE)でもWiresharkでSSL/TLSを復号すべく試行錯誤したので、まとめます。 事前の設定内容 VirtualBoxで以下のゲストOSやApacheを立ち上げておきます。 $ cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) $ httpd -v Server version: Apache/2.4.6 (CentOS) Se
static-DHによるSSL/TLS - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 一体何の話なんです? SSL/TLSというのは、ご存じの通り、4種類の機能 Kx(鍵交換),Au(認証),Enc(暗号),Mac(ハッシュ/AEAD) を組み合わせたハイブリッド暗号技術です。 ここに、DHやECDHという鍵交換の方式が使われていることもご存じとは思いますが、ほとんどの場合それは、DHEやECDHEといったEphemeral(一時キー)版を指します。 しかし…。おそらく超マイナーながら、EphemeralでないDH,ECDH、通称static-DH,static-ECDHを使う方式もプロトコル上はあるのです。
SSL/TLSネゴシエーション
◆ SSL/TLSセッションのハンドシェイク SSLクライアントとSSLサーバとでやりとりされるメッセージのなかで、以下のメッセージについては やりとりを省略した通信が行われる場合もあります。 ・ Server Certificate ・ Server Key Exchange ・ Certificate Request ・ Client Certificate ・ Certificate Verify 例えば、クライアント証明書を使用しないSSL通信であれば「Client CertificateとCertificate Verify」が省略。 ◆ SSL/TLSのメッセージ ・ Client Hello SSLの通信開始をクライアントからサーバに通知するメッセージ。メッセージに含まれている内容は以下です。 ⇒ SSL/TLSのバージョン、乱数、セッションID、クライアントが利用できる暗号
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Nginx reverse proxy to Heroku fails SSL handshake