Google Chromeチームは10月3日(米国時間)、「Google Online Security Blog: No More Mixed Messages About HTTPS」において、ChromeではHTTPS/HTTP混在ページにおけるHTTPをデフォルトでブロックの対象としていくと伝えた。挙動の変更は年末から2020年第1四半期にわたってリリースされるChromeで順次行われる。 予定されている挙動変更のスケジュールは次のとおり。
[レベル: 中級] セキュリティに関する Chrome ブラウザの UI 変更を Google はアナウンスしました。 HTTPS および HTTP ページのインジケータが将来のバージョンの Chrome で変わります。 鍵アイコンと「保護された通信」ラベルの削除 HTTPS で配信されるページに対して表示されるラベルとアイコンが削除されます。 現在は、HTTPS ページにアクセスしていると鍵アイコン🔒と「保護された通信」ラベルがアドレスバーの先頭に表示されます。 2018年9月にリリースされる Chrome 69 ではラベル表示がなくなり、鍵アイコンだけになります。 「https://」のスキームもなくなります。 最終的には鍵アイコンも表示しなくなる予定とのことです。 HTTPS 通信であることがわからなくなりますが、セキュリティが守られていることがウェブでは当たり前だとユーザーは想定
今日は、常時HTTPS化とドメイン名変更に関する話題を。Web担では10月にこの両方を一気に進めましたが、検索エンジンからのトラフィック減など一切なしに完了しました。そこでやった手順をお届けします。 ドメイン名を変えるなら常時HTTPS化もWeb担では、オープン当時の社名に基づくドメイン名「impressrd.jp」を長らく使っていましたが、すでに会社が「株式会社インプレス」になっているため、全社的な統一性の観点からドメイン名を変えることにしました。 そして、ユーザーログイン機能があるサイトであるため、Wi-Fi環境でのセキュリティ担保なども目的として、常時HTTPS化を行いました。 旧URL: http://web-tan.forum.impressrd.jp/ 新URL(ドメイン名変更+HTTPS化): https://webtan.impress.co.jp/ 実は、この移行作業には
SSLの普及を促すために無料で発行できる証明書「Let’s Encrypt」 種類的にはDV証明書ですが、本番運用でDV証明書を使ってるサイトは多いはず。 しかし本番にLet’s Encryptを使うのは…と考えて、 結局本番環境には証明書を買う。みたいな運用をしてるところもあると思います。 実際本番環境でLet’s Encryptを使用しているサイトはどれくらいあるのか? 気になったので調べてみました! 調査方法 まずどうやって調査したか記載します。 サイトの選定方法 世界中すべてのサイトのURLがわかる方法がないので Alexaに掲載されているサイトで調査しました。 Alexaは世界中のサイトのアクセス数などが記録されており、 無料でアクセスランキング上位50位まで公開されています。 世界 各国ごと ジャンルごと と細かくランキングが分かれてるので、様々なサイトURLがここで取得できま
ピクシブ株式会社で開発基盤チームとして働いている @catatsuy です。主にpixivの技術的な改善をしていますが、広告チームも兼任しているので広告周りの開発もしています。 今回pixivの常時HTTPS化を担当したのでやったことを紹介します。 pixivをHTTPS化した理由 現在のインターネット全体の流れとして常時HTTPS化が進んでいます。エドワード・スノーデン - Wikipediaが暴露したNSAの事件発覚や 公衆無線LANの利用拡大により、通信経路上でユーザーの個人情報を保護することがインターネット全体として非常に重要になってきました。Googleが行っている調査によると、HTTPSページの閲覧時間はウェブ全体の利用時間の3分の2にも及びます。 それだけではありません。ブラウザに新しく追加されるAPIや機能(HTTP2/WebRTC/ServiceWorkerなど)はHTT
インフラエンジニアの方向けに、SSL/TLSとは何か、また証明書入手のポイント、HTTPS設定のポイントについて、最新の動向を踏まえて紹介します。また、最後の方で勉強会主催者のリクエストでおまけがあります(^^;
Web サイトを常時 SSL 化する場合に、最低限知っておかなければならない知識や、注意点、実際の設定方法まで、ひと通りまとめてみました。メリットやデメリット、証明書の種別からリダイレクト設定などについても解説しています。 HTTPS をランキングシグナルに使用しますと Google が公式に発表したあたりから、Web サイトの SSL 対応、特に Google が推奨している Web サイトをすべて HTTPS で配信する、所謂 「常時 SSL 化」 についての話を聞いたり、実際にお客様から相談されたりするケースが増えてきました。 そこで、いい機会だしその辺に関する情報をまとめておこうかな~ と思って書いてみた、恒例の (?) 5分でわかるシリーズ。書き終わって見たところ絶対に 5分じゃ無理っていう文章量になっててどうしようかなぁとも思ったんですが、気にせず公開してみます。 常時 SSL
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
こんにちは検索サービス開発4チームの崔珉秀と申します。 インフラやシステムとの連携や統計のバックエンドを担当しております。 モバイルのウェブ環境はPCのウェブ使用環境とは色々な違いが有ります。 ネットワークの速度だけではなくバッテリーの効率を考えた仕組みなど、PCに比べリソースが十分ではないためモバイルブラウザの動作が異なっていることも有ります。 今回はモバイルのウェブApplicationにおけるSSL関係の性能に関する工夫の内容をQ&A形式で解説していきます。 Q. 何が問題でしたか? A. モバイルクライアント(iPhone, Android)のアプリケーションからのHTTPリクエストの応答時間に遅延の問題が有ります。 最初はweb access logからのslow response(1秒以上)のHTTPリクエストが結構ありました。 そのHTTPリクエストをprotoc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く