ローカル開発環境の https 化 | blog.jxck.io
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う
お願いがあります．オリジンサーバを暗号化なしの HTTP で運用しないでください． - Qiita
インフラもセキュリティも，まだまだ未熟な私ではありますが，これだけはお願いします． オリジンサーバを暗号化なしの HTTP で運用しないでください． TL;DR ここで，オリジンサーバは，ファイアウォールやゲートウェイを通った先の最も奥にある，最終的にリクエストを処理するサーバをいいます．アプリケーションサーバが当てはまることが多いですが，静的ファイルサーバも例外ではありません．対して，間に入るサーバをエッジサーバと呼ぶことにします． また，この記事では暗号化なしの HTTP を HTTP ， TLS レイヤ上の HTTP を HTTPS として記述します．HTTPS における TLS 上での通信も HTTP ではあるため，差別化のために明記しておきます． 何がだめなのか 近年， Web サイトのほとんどが TLS を用いた HTTPS で運用されています．パブリックな静的コンテンツに対し
.appという画期的でセキュアなgTLDについて - Lento con forza
.appというgTLDをご存知でしょうか。gTLDはgeneric top-level domainの略後で、ICANNが管理しているトップレベルドメインのことです。 有名どころでは.comや.net等があります。このブログのURLは https://kouki.hatenadiary.com ですが、この.comの部分がトップレベルドメインです。*1 このトップレベルドメインはICANNという組織が管理しています。2012年までは限られたトップレベルドメインしか存在しませんでしたが、2012年の公募では基準を定め、その基準を満たした団体は自由にgTLDを作ることができるようになりました。これ以降大量のトップレベルドメインが登録され、今では様々なドメインを利用することができます。 その中の一つ、appドメインが去年話題を呼びました。 appドメインはセキュアなドメイン そんなappドメイン
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか？ 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途
社内システムがHTTPで運営されている企業へのHTTPS化の指摘・要望はどのようにするべきでしょうか？
先日、保険に入ろうと思っていつもお世話になっている保険会社の方に連絡を入れ資料説明等を受けていたのですが、その会社の顧客管理・営業用システムがWebを使ったシステムで、営業マンの方は、私が加入している保険や個人情報などをタブレット端末で確認しながら説明をして下さっていたのですが、ブラウザのurlがhttp://... になっていました。 インターネットには、小型のポケットルータを使って接続しているようでした。 この保険会社に関わらず、これまでにも社内システムをSSL無しで構築されているのをなんどか見たことがあり、その度に見なかったことにして「あっ、察し・・・」ということでそっと離れていくか、話の分かってもらえそうな人であれば「ちゃんとした方がいいと思いますよ」的なことをお伝えしてきたのですが、今回の場合、既に自分がその会社の保険に加入しており簡単にそっと離れていくということもできず、SSL
HTTPS Everywhere | Electronic Frontier Foundation
You no longer need HTTPS Everywhere to set HTTPS by default! Major browsers now offer native support for an HTTPS only mode. Learn how to turn it on. Read more about the sunset of HTTPS Everywhere. Since we started offering HTTPS Everywhere, the battle to encrypt the web has made leaps and bounds. Now HTTPS is truly just about everywhere, and the web has largely switched from non-secure HTTP to th
mixed contents 対応を促進する CSP ディレクティブ | blog.jxck.io
Intro HTTPS 移行の問題点の一つに、 mixed contents への対応がある。 逆に mixed contents の発生を恐れ、 HTTPS に移行できないサービスもあるだろう。 本エントリでは mixed contents の正しい理解と、その検出や解消に利用できる可能性のある、 CSP の Upgrade-Insecure-Request および、 Block-All-Mixed-Contents を解説する。 mixed contents HTTPS で配信されたコンテンツが、サブリソースとして HTTP のコンテンツを含む場合、これを mixed contents という。 HTTPS は MITM に対する耐性があるが、 HTTP は MITM への耐性がないため、 mixed contents の状態ではサブリソースを起点にメインコンテンツへの改ざんが成立して
HTTPS でも Full URL が漏れる？OAuth の code も漏れるんじゃね？？ - OAuth.jp
なんですかこれは！ New attack bypasses HTTPS protection on Macs, Windows, and Linux DHCP につなぐと PAC ファイルがダウンロードされて HTTPS であろうとアクセス先の Full URL は漏れるですって？ Web Proxy Autodiscovery ですって？ チョットニホンゴデオネガイシマス ってことで、まぁこれが実際どれくらい簡単に実現できる攻撃パターンなのかは他のセキュリティ業界の方々に後で聞くとして、この記事でも触れられてる OpenID Connect とか OAuth2 への影響について、ちょっとまとめておきましょうか。 Authorization Request & Response が漏れる response_mode=form_post なんていうのも一部ありますが、基本 OAuth2 /
New attack bypasses HTTPS protection on Macs, Windows, and Linux
A key guarantee provided by HTTPS encryption is that the addresses of visited websites aren't visible to attackers who may be monitoring an end user's network traffic. Now, researchers have devised an attack that breaks this protection. The attack can be carried out by operators of just about any type of network, including public Wi-Fi networks, which arguably are the places where Web surfers need
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
Public Key Pinning for HTTP(HPKP) 対応と report-uri.io でのレポート収集 | blog.jxck.io
Intro 本サイトにて Public Key Pinning for HTTP を有効化した。 CSP 同様、まずは Report-Only を設定し、 HPKP Report についても、 report-uri.io を用いて収集することにした。 導入に必要な設定や、注意点についてまとめる。 なお、本サイトへの導入はあくまで 実験 である。運用や影響も踏まえると、一般サービスへの安易な導入は推奨しない。 また、本来は HSTS と併用することが推奨されている。(必須ではない) そちらも追って対応する予定である。 Public Key Pinning 概要 Public Key Pinning for HTTP(HPKP) とは、証明書の信頼性を向上させる仕組みである。 RFC 7469 - Public Key Pinning Extension for HTTP 本サイトは HTTP
Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes
Intro 先日 #http2study で mozilla の Richard Barnes が Let's Encrypt について話してくれました。 資料: Let's Encrypt Overview この資料の翻訳 はしたのですが、いらなくなってしまったので供養もかねてこのプロジェクトのモチベーションと、 Web でおこっている HTTPS 推進のたどる道について、資料を補足しつつ紹介します。 結論から言うと Let's Encrypt はもちろん ACME プロトコル についても是非知っておくと良いと思います。 HTTPS の問題 すでにこのブログでも紹介しているように、 Web における HTTPS の重要性は増し、それの普及を後押しする活動が各所で進められています。 HTTPS 化する Web をどう考えるか よく言われる盗聴防止を始め、暗号化を行うことで防げる問題は多くあ
Strict-Transport-Security - HTTP | MDN
HTTP ガイド リソースと URI ウェブ上のリソースの識別 データ URL MIME タイプ入門 よくある MIME タイプ www 付きと www なしの URL の選択 HTTP ガイド HTTP の基本 HTTP の概要 HTTP の進化 HTTP メッセージ 典型的な HTTP セッション HTTP/1.x のコネクション管理 プロトコルのアップグレードの仕組み HTTP セキュリティ Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) X-Content-Type-Options X-Frame-Options X-XSS-Protection サイトの安全化 HTTP Observatory HTTP アクセス制御 (CORS) HTTP 認証 HTTP キャッシュ HTTP の圧縮 HTT
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あらゆるPC/Macから情報を抜き取れる5ドルのラズパイデバイスが公開 ～対抗手段はUSBポートをセメントで固めること