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
powの.devドメインがChromeで使えなくなったので.testも使える様にする
B! 8 0 2 0 このブログをMacでローカルでレビューする時には Pow を使ってますが、 デフォルトで指定されている.devというドメインが Google Chrome上では扱いが面倒な事になっているので .testというドメインで使える様にしました。 Pow Chromeでの問題 解決法 Pow PowはMac (OS X)で使えるRackを使ったウェブサーバーで ~/.pow/というディレクトリの下にサイトのトップディレクトリを置いておくと、 http://directory_name.devというURLで見れる様にしてくれるツールです。 Octopressでのプレビュー方法 Macでは1番使うのが楽です。 powというプロセスが常時作動する様になりますが 使ってない時はほとんどリソースを使わないので無視できる程度です。 通常HTTPな接続ですが、HTTPSな接続を試したい時は
DNS over HTTPSの標準化開始:Geekなぺーじ
DNSのメッセージをHTTPSの上に乗せようという標準化活動がIETFで開始されました。 IETFのDOH(DNS Over HTTPS)ワーキンググループです。 DOHワーキンググループは、Applications and Real-timeのエリアです。 先月開催されたIETF 100(2017年11月)にて、DOHワーキンググループの第1回ミーティングが行われました。 そこでは、ワーキンググループが対象としている範囲や、現在あるインターネットドラフトに関しての議論が行われました。 draft-ietf-doh-dns-over-https : DNS Queries over HTTPS 現段階におけるインターネットドラフトは、以下のような内容が最初に書かれています。 DNS queries sometimes experience problems with end to end
Web サービスの完全 HTTPS 化 - クックパッド開発者ブログ
インフラストラクチャー部長の星 (@kani_b) です。 2017年1月5日をもって、クックパッド における全ページで HTTPS が使われるようになりました。 完全 HTTPS 化をするにあたり、その理由や具体的な進め方について紹介します。 以前 SRE Tech Talks #2 にて一部発表した内容も含みますので、ご興味のある方はあわせてスライドもご覧ください。 完全 HTTPS 化に踏み切った理由 以前のクックパッドは、ログインや登録情報の参照など、いわゆる個人情報や認証情報を扱う箇所のみに HTTPS が使われていました。 このように「必要な箇所にのみ HTTPS を使う」構成は、ある程度歴史のある Web サービスにおいてよく使われている構成です。 この状態から、完全 HTTPS 化に踏み切った理由を説明します。 サービスをよりセキュアにするため HTTPS の利用を考えるに
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 の状態ではサブリソースを起点にメインコンテンツへの改ざんが成立して
Google Public DNS over HTTPS を試す | IIJ Engineers Blog
【2018/11/16 追記】 本記事は、2016 年 4 月に Google Public DNS サーバに実装された、実験的な DNS over HTTPS プロトコルについて紹介しています。DNS over HTTPS プロトコルはその後 IETF の doh ワーキンググループにて標準化が進められ、2年半後の 2018 年 10 月に RFC8484 として出版されました。本記事で紹介したプロトコルは RFC8484 に規定されたプロトコルとはいくつもの点で異なっていることにご注意ください。 Google Inc. が公開 DNS サーバを運営していることはご存知でしょうか? Google Public DNS と呼ばれるこの公開 DNS サーバは、”8.8.8.8″ という特徴的な IP アドレスで全世界のインターネットユーザに対して無料の DNS サーバ(フルレゾルバ)を提供し
HTTPSにまつわる怪しい伝説を検証する - Google I/O 2016のセッションから - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 今年はGoogle I/Oに初めて社員ではない立場で参加しました。全体の感想は Google I/O 2016まとめ（Web的視点） で公開していますが、今回はその中で、気に入ったセッションの1つである"Mythbusting HTTPS: Squashing security’s urban legends"について書いてみたいと思います。 セッションは大変良くまとまっていますので、YouTubeにあがっている動画を見れる人は動画を見て貰えれば良いのですが、時間が無いという人のために、その内容をまとめました。基本的には文字起こしに近い
Implementing SSL on Amazon S3 Static Websites
Since this post was written, Amazon has launched AWS Certificate Manager, which provides certificates at no cost and substantially simplifies managing them for use in the AWS context. We recommend that readers investigate the AWS Certificate Manager product before following the guidance in this post. Every day, more and more websites are serving their pages using HTTPS. This can lead to warnings o
アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について - s_tajima:TechBlog
問題 アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について調べた。 該当のサーバでは、以下のようにメモリの使用率が徐々に上昇していく。 また、アプリケーションのプロセス自体がメモリを消費しているわけではない状態。 原因 調査すると、このバグ仕様を踏んでいるのではないかと思われるページを見つけた。 https://bugzilla.redhat.com/show_bug.cgi?id=1044666 内容としては、curlを実行した際に /etc/pki/nssdb/以下の存在しないファイル(毎回違うパス)に対してaccessシステムコールが大量にコールされ、 negative dentry cacheが溜まっていき、メモリ使用量が圧迫されるというもの。 実際、この状況が起きているサーバを調べるとメモリ使用率のうち多くを占めているのはnega
5分でわかる正しい Web サイト常時 SSL 化のための基礎知識
Web サイトを常時 SSL 化する場合に、最低限知っておかなければならない知識や、注意点、実際の設定方法まで、ひと通りまとめてみました。メリットやデメリット、証明書の種別からリダイレクト設定などについても解説しています。 HTTPS をランキングシグナルに使用しますと Google が公式に発表したあたりから、Web サイトの SSL 対応、特に Google が推奨している Web サイトをすべて HTTPS で配信する、所謂 「常時 SSL 化」 についての話を聞いたり、実際にお客様から相談されたりするケースが増えてきました。 そこで、いい機会だしその辺に関する情報をまとめておこうかな～ と思って書いてみた、恒例の （？） 5分でわかるシリーズ。書き終わって見たところ絶対に 5分じゃ無理っていう文章量になっててどうしようかなぁとも思ったんですが、気にせず公開してみます。 常時 SSL
HTTPSを使うなら“HSTS”と“HSTSプリロード”でセキュリティを高めよう など10+4記事 | 海外&国内SEO情報ウォッチ
HSTS（HTTP Strict Transport Security）という仕組みがある。簡単にいうと、次のような仕組みだ。 「このサイトにはHTTPではなくHTTPSで必ず接続するように」と、サーバーがブラウザに指示するHTTPヘッダー。この指示を受け取ったブラウザは、その情報を記録しておき、以降は、そのサイトに対してアクセスするのにHTTPを使わず自動的にHTTPSで接続するようにする。 たとえHTTPSでサイトを構成していたとしても、通信を傍受されたりフィッシング詐欺に遭ったりする危険性がある（特に無線LANなどの環境で）。これを防ぐのにHSTSを利用できる。 グーグルは、HTTPSをランキング要因に組み込んだことを発表した際に、「サイトでHSTSを有効にするように」と指示している。 ところが、たしかにHSTSによってブラウザは必ずHTTPSで接続を試みるのだが、それは2回目以降だ
HTTPからHTTPSへの移行で出てきた質問に回答
[対象: 中〜上級] Googleは、HTTPSをランキングシグナルとして取り入れました。 HTTPからHTTPSへ移行する際のサイト管理者たちからの質問にGoogleのJohn Mueller（ジョン・ミューラー）氏がGoogle+で回答しています。 僕たちにも参考になるので紹介します（すべてではありません。一部はHTTPS Everywhereからです）。 HTTPS移行への質問に対するジョン・ミューラー氏から回答 Q: 「HTTPSを考慮に入れる」というのは、HTTPSページの順位を上げるということか？ A: そのとおり。今のところはわずかだが、HTTPSのほうが上位になることがある。 Q: EV SSLなどサーバー証明書には種類があるがどれにすべきなのか？ A: 種類は問わない。今のところGoogleが条件に【UPDATE】推奨しているのは 2048 bit（以上）の証明書であるこ
OpenSSLの脆弱性（CVE-2014-0224）への対応方法（AWSサービス/OSごと） ※随時更新中 - サーバーワークスエンジニアブログ
大阪オフィスの桶谷です。こんにちは。 今週から大阪オフィスにも1人メンバーが増えました。祝ぼっち脱出。 さて、先日のHeartbleedに続いて、またしてもOpenSSLの脆弱性が発見されました。今回はCCS Injectionです。 ということで対応方法をまとめてみました。 ※最終更新 2014/06/11 1:00 CCS Injection脆弱性(CVE-2014-0224)の概要・対策・発見経緯について 株式会社レピダム さんの脆弱性発見ニュース http://lepidum.co.jp/news/2014-06-05/news-CCS-Injection/株式会社レピダム さんの脆弱性の概要説明 http://ccsinjection.lepidum.co.jp/ja.htmlOpenssl.org https://www.openssl.org/news/secadv_2014
iOS実機のSSL通信をプロキシによって傍受したり改ざんする方法 - Qiita
はじめに スマートフォンアプリ開発でAPIを介しWeb/APIサーバーとやりとりをする場合、「httpsを使っていれば通信はユーザーにバレない」なんてことはなく、Webアプリでツールを使ってできるのと同じようにユーザーには通信内容の確認や改竄などができます。 そのため、そのことを前提にアプリやサーバーAPIの設計と実装を行わない場合、アプリ利用者によるゲームスコア結果送信の改竄や、ソーシャルゲームにおけるレイドボスなどへのダメージ操作、ECサイトアプリでの購入操作なども可能になってしまいます。 また、最近自分は「無料で音楽聴き放題!! - ネットラジオ」というアプリをリリースしたのですが、このアプリに導入するスタティックリンクライブラリが不明な外部サーバーへ通信していないか、SSLを使用しているつもりがそうでない通信をしてしまっていないかのチェックをするため、自分はmitmproxyという
[メモ] Apache+mod_sslでSIGBUSが発生した件
@hirose31さんと、Apache HTTPDからHTTPSでファイルダウンロード中にサーバプロセスがSIGBUSで死ぬって件にぶちあたり、 「OpenSSLの中でmemcpyがSIGBUSしてます」「な、なんだってー！」 って調べたのですが、理由は以下のとおりだった。 HTTPSの場合、デフォルト設定だとファイル読込にmmap(2)が使われる mmapされたファイルのサイズが変更されてもApacheはそれを検知しようがない そして、ファイル末尾以降のデータを読もうとするとセグメンテーションエラー(SIGBUS)が発生し、Apacheのサーバプロセスは異常終了する HTTPの場合は、ローカルファイルシステムの場合sendfile(2)が使われるので、ファイルサイズが変更になってもApacheは異常終了しない ただし、mod_deflateのような出力フィルタを使っている場合は、HTTP
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - SteveLTN/https-portal: A fully automated HTTPS server powered by Nginx, Let's Encrypt and Docker.
GitHub - naoya/sukushokun
https://jp.techcrunch.com/2014/11/19/20141118mozilla-eff-and-others-band-together-to-provide-free-ssl-certificates/
seo-matome.jp
