HTTPS 証明書の Common Name の検証がしれっと禁止されていた件について | IIJ Engineers Blog
開発・運用の現場から、IIJのエンジニアが技術的な情報や取り組みについて執筆する公式ブログを運営しています。 こんにちは。IIJ Engineers Blog編集部です。 IIJの社内掲示板では、エンジニアのちょっとした技術ネタが好評となって多くのコメントが付いたり、お役立ち情報が掲載されています。 今回は、すでにお気づきの方もいるかもしれませんが、いつの間にか HTTPS 証明書の Common Name の検証が禁止 になっていた件について紹介します。 HTTPS 証明書の検証手続きは、RFC2818 で「Subject Alternative Name があればそれで、なければ Common Name を見よ」となっていました。 If a subjectAltName extension of type dNSName is present, that MUST be used as
数百万件残っていたHTTPのはてなブログを4年越しにすべてHTTPS化させた話 - Hatena Developer Blog
こんにちは id:cohalz です。はてなブログでは2021年4月の公式ブログで、すべてのブログをHTTPSに一本化していくことを案内しました。 ▶ 「HTTPS配信」への切り替えと、ブログの表示の確認をお願いいたします この時点でまだ数百万件のHTTPのブログが残っている状態でしたが、2021年8月には上記の案内に追記したように、全ブログでHTTPS化を完了できました。 完了までに行ってきたことをこの記事で振り返ってみようと思います。 はてなブログのHTTPS化のこれまで はてなブログのHTTPS化は、2017年9月に最初のお知らせを行ってスタートしました。 当初の予定より時間がかかりましたが、2018年2月にHTTPS配信の提供を開始し、これ以降に作成されたブログは最初からHTTPSのみで配信されています。また、それ以前に作成されたブログでも、ユーザ側で設定を変更することで自分のブロ
【図解】透過型プロキシの仕組み ～https(SSL/TLS)への対応～
透過型プロキシとは透過型プロキシ (Transparent Proxy) とは、ブラウザにプロキシの設定をしていない状態でもプロキシサーバ経由による Web アクセスをさせる方法です。透過プロキシとも言います。 フリーウェアの Squid でも実現できますし、商用プロキシの BlueCoat や i-filter 等でも機能を持っています。 仕組みとしては、インターネットへの通信経路上に透過プロキシの設定をしたプロキシサーバを配置するのみです。 以下に、通常のプロキシと透過型プロキシの通信の比較を示します。 「インターネットへの通信経路上」といっても、デフォルトルートの経路上に配置してしまうと、smtp や pop, imap 等の他のプロトコルがインターネット通信できなくなってしまいます (http 等の一部のプロトコルのみ、透過型プロキシサーバで取り次がれますので)。 なので、透過型プ
TLS1.3時代の新常識
TLS • TLS (reliable) endpoint endpoint CC BY 3.0 https://www.youtube.com/user/TheWikiLeaksChannel ClientHello+ ApplicationData end_of_early_data Finished ServerHello EncryptedExtension ServerConfiguration Certificate CertificateVerify Finished ApplicationData
次世代Webカンファレンス 2019：HTTPSセッションが面白かった - ろば電子が詰まつてゐる
以前から気になっていた「次世代 Web カンファレンス 2019」を、ようやく聴きに行くことができました。 たくさんのトークがありましたが、ここではHTTPS (hashtag: #nwc_https)をメモしておきます。なお、このセッションが間違いなく一番アツく、一番面白かったです! 当日の動画 https://www.youtube.com/watch?v=_8dCa8wj8QY togetter https://togetter.com/li/1268794 以下、当日参加した、もしくは動画を見たという前提でのメモなので、見てない人はぜひ見ましょう。 PKI 「低レイヤから行きましょう」ということで、はじめはPKI絡み。Symantecのdistrustと、日本のGPKIの話でした。 トーク中に何度か出てきましたが、認証局(厳密にはCAとRAを分けて書くべきですが、どうせみんな一緒な
HTTP/1.x⇒HTTP/2 仕様変更で困ったこと (利用暗号の制約・httpヘッダーの小文字化) - Qiita
はじめに こちら、そろそろ知っておきたいHTTP/2の話という良くまとめられた記事を見ていて、色々と苦い記憶がよみがえってきたのですが、そういうHTTP/2仕様に困った系記事があまり見当たらなかったのでまとめました。 HTTP/2とは 機能 現在支流のHTTP 1/1よりもより効率よく、セキュアな通信をもらたす為に色々なアップグレードを施したHTTPの規格です。 特徴をざっというと、こんな感じ。 ストリーム、メッセージ、フレームという新しいデータの交換方式を利用することによる、実TCPセッション数削減 サーバー プッシュ機能により、複数のレスポンスが送信可能 HTTPヘッダーの仕組みを見直し、ヘッダー圧縮によるネットワーク負荷軽減 HTTPS(TLS)との関係 実はHTTP/2はHTTPSと深い関係があります。 実質的にHTTPS必須、しかもTLS1.2以上、cipher-suiteはTL
curlで異なるFQDNにhttpsアクセスする方法 - Qiita
やりたいこと curlを使って、test.example.com(10.0.0.2) というサーバーに対して https://www.example.com としてアクセスしたい 回答 1 /etc/hostsかきかえる(よくある) でも、書き換えたの忘れてあとでハマるのでオススメではないです。 回答 2 --resolve オプションを利用する。 例： curl -H 'Host:www.example.com' --resolve 'www.excample.com:443:10.0.0.2' https://www.example.com/ 敗北した方法 ホストヘッダのみ書き換える curl -H 'Host:www.example.com' https://test.example.com/ バーチャルホストにアクセスする場合に有効ですが、HTTPの処理の前にTLSの処理があるの
作って学ぶ 「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メソッ
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか？ 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途
pixivを常時HTTPS化するまでの道のり（後編） - pixiv inside
ピクシブ株式会社で開発基盤チームとして働いている @catatsuy です。 前編ではpixivを常時HTTPS化する前にやった前準備として、広告、画像といったリソースをHTTPSに切り替える際の手順を紹介しました。 pixivを常時HTTPS化するまでの道のり（前編） - pixiv inside 後編では実際にpixivのアプリケーション自体を常時HTTPS化していく手順を紹介します。 従来のHTTPS配信 pixivはPHPアプリケーションを実行するアプリケーションサーバー(Apache/mod_php)の前段にnginxを配置する構成になっています。以前からセキュリティ的に重要なページはHTTPSで提供しており、nginxでHTTPS終端処理を行っていました。HTTPSで応答する場合はアプリケーションサーバーにX-HTTPSヘッダーを付けてプロクシーしています。 具体的には以下のよ
pixivを常時HTTPS化するまでの道のり（前編） - pixiv inside
ピクシブ株式会社で開発基盤チームとして働いている @catatsuy です。主にpixivの技術的な改善をしていますが、広告チームも兼任しているので広告周りの開発もしています。 今回pixivの常時HTTPS化を担当したのでやったことを紹介します。 pixivをHTTPS化した理由 現在のインターネット全体の流れとして常時HTTPS化が進んでいます。エドワード・スノーデン - Wikipediaが暴露したNSAの事件発覚や 公衆無線LANの利用拡大により、通信経路上でユーザーの個人情報を保護することがインターネット全体として非常に重要になってきました。Googleが行っている調査によると、HTTPSページの閲覧時間はウェブ全体の利用時間の3分の2にも及びます。 それだけではありません。ブラウザに新しく追加されるAPIや機能（HTTP2/WebRTC/ServiceWorkerなど）はHTT
Moving to HTTPS - migrate from HTTP to HTTPS with ease.
A community site to help site owners migrate to HTTPS with a simple tested process. Allowing you to filter the plan based on multiple platforms (WordPress, Magento, and more), hosting environments (cPanel, Apache, and more) along with the level of control / access you have over the site. Are you migrating your site from HTTP to HTTPS? Join in with #movingtoHTTPS Looking to contribute? All of this
Web over HTTPS
Web over HTTPS DevFest Tokyo 2016 #devfest16 2016/10/0
HTTP/2とTLSの間でapacheがハマった脆弱性(CVE-2016-4979) - ぼちぼち日記
0. 短いまとめ 昨晩apache2.4でHTTP/2利用時にTLSクライアント認証をバイパスする脆弱性(CVE-2016-4979)が公表され、対策版がリリースされました。 実際に試すと Firefoxで認証バイパスができることが確認できました。 HTTP/2でTLSのクライアント認証を利用するには仕様上大きな制限があり、SPDY時代から長年の課題となっています。 この課題を解決するため、Secondary Certificate Authentication in HTTP/2という拡張仕様が現在IETFで議論中です。 1. はじめに ちょうど昨晩、apache2.4のhttpdサーバの脆弱性(CVE-2016-4979)が公開され、セキュリティリリースが行われました。 CVE-2016-4979: X509 Client certificate based authenticatio
この時期HTTPSとHTTP/2への移行はセットだよなあ - 仮想と現実
HTTP/2というのはHTTPプロトコルバージョン２の事である。スペースダンディは宇宙のダンディであるというのと同じくらいわかりやすい解説である。 冗談はさておいて、今までのHTTPが、HTMLやら画像やらCSSやらスクリプトやら、Webページに含まれる要素を一個一個接続、取得、切断の繰り返しで取得してたのに対し、HTTP/2では接続したら一度に全部取得して高速化しちゃおうぜって感じのものなわけで、他にもいろいろ高機能化してる。なのでできればWebサイトはさっさとHTTP/2に移行したほうがいろいろといいことがあるよって話だ。 で、このHTTP/2、規格にはHTTP接続で使用する方法も書いてあるのだけど、なんか主なブラウザの実装が全部HTTPS上でしかHTTP/2が使用できないものになってるんだよね。なのでHTTP/2にしたければ、サーバ側はセットでHTTPS対応もやらなきゃいけないと言う
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
Let's Encryptを使用したkame.photosのSSL Server Test結果をA+にした - カメニッキ
https://kame.photos/ 参考 細かすぎて伝わらないSSL/TLS - Yahoo! JAPAN Tech Blog Generate Mozilla Security Recommended Web Server Configuration Files SSL Server Test: kame.photos (Powered by Qualys SSL Labs) NginxでSSLの評価をA+にする手順 - 9mのパソコン日記 我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita http { 〜略〜 # HTTP Strict Transport Security の指定。サブドメインにも適用 add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains;';
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
大規模HTTPS導入Night #https_jirei
https://investment81.net/one-demerit-ssl/
cookpad.com 全 HTTPS 化の軌跡
