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
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか？ 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途
こんにちは、 tomoasleep です。ハイカラスクエアではシャケを狩るバイトに明け暮れています。 Qiita はリリース時からユーザーの認証などに関わる一部のページを除き HTTP を使って配信してきましたが、この度全ページを HTTPS 化しました。実施の背景やユーザーの皆さんへの影響などを簡単に解説します。 なお本ブログ記事は Qiita に関してのお知らせであり、Qiita:Team はリリース時より一貫して HTTPS を使っています。 HTTPS とはインターネットは世界中の様々なネットワークを接続して作られています。そのためインターネットには常に経路上での盗聴や通信情報の改ざんなどの脅威が存在します。 HTTPS を利用することにより、それらを防ぐことが出来るようになります。 （HTTPS に関する技術的で詳しい解説は Qiita にたくさんあるのでそちらを参照してしてみて
はじめに Amazon Certificate Manager(以降、ACM)から取得したSSL/TLS証明書についての有効期限について書いてみます。 ACMで提供されるSSL/TLS証明書は13ヶ月の有効期限が設定されており、有効期限間近になるとACM側で自動更新が実施されます。 ですが、一部の証明書は自動更新が実施されずに手動にて更新を行う必要があります。 どういった時に自動更新されないか？ ACMで管理されている証明書で自動更新が実施されない理由は以下になります。 自動更新プロセス適用条件 AWS Certificate Manager (ACM) 証明書の自動更新時の注意点 通常、ACM では自動で証明書更新が完了いたします。ご利用者側で証明書をインストールしたりソフトウェアを更新いただく必要はありません。自動更新による通信の瞬断もありません。証明書の保守管理が理由でWebサイトな
ピクシブ株式会社で開発基盤チームとして働いている @catatsuy です。主にpixivの技術的な改善をしていますが、広告チームも兼任しているので広告周りの開発もしています。 今回pixivの常時HTTPS化を担当したのでやったことを紹介します。 pixivをHTTPS化した理由 現在のインターネット全体の流れとして常時HTTPS化が進んでいます。エドワード・スノーデン - Wikipediaが暴露したNSAの事件発覚や 公衆無線LANの利用拡大により、通信経路上でユーザーの個人情報を保護することがインターネット全体として非常に重要になってきました。Googleが行っている調査によると、HTTPSページの閲覧時間はウェブ全体の利用時間の3分の2にも及びます。 それだけではありません。ブラウザに新しく追加されるAPIや機能（HTTP2/WebRTC/ServiceWorkerなど）はHTT
インフラストラクチャー部長の星 (@kani_b) です。 2017年1月5日をもって、クックパッド における全ページで HTTPS が使われるようになりました。 完全 HTTPS 化をするにあたり、その理由や具体的な進め方について紹介します。 以前 SRE Tech Talks #2 にて一部発表した内容も含みますので、ご興味のある方はあわせてスライドもご覧ください。 完全 HTTPS 化に踏み切った理由 以前のクックパッドは、ログインや登録情報の参照など、いわゆる個人情報や認証情報を扱う箇所のみに HTTPS が使われていました。 このように「必要な箇所にのみ HTTPS を使う」構成は、ある程度歴史のある Web サービスにおいてよく使われている構成です。 この状態から、完全 HTTPS 化に踏み切った理由を説明します。 サービスをよりセキュアにするため HTTPS の利用を考えるに
この記事はなんたらAdventCalendarとは関係のないただのメモです。 このへんの分野はあんまり強くないものの、手探りでやってみてなんとかできたのでその学びを。 基本的にはこのリンクを参考にしたけども、内容を理解するまでにいろいろ壁があったので・・。 Let's Encryptで複数サブドメインの証明書を発行して自動更新を設定する - Qiita 環境は、 CentOS 6.8 nginx 1.0.15 nginxのバージョンは後であげた。 はじめに そもそも気になってたことなので改めて書いておきます。 Let's EncryptってサブドメインもまとめてHTTPS化できるの？ できます！ ワイルドカードできる証明書じゃないのでちょっと手間はかかるができる。 というわけでざっくり手順 certbot いれる acme-challenge用のlocationを作る 既存のser
こんにちは。生産性向上チームの宮田（@miyajan）です。 サイボウズには、生産性向上チームという、組織横断で使える開発基盤を整備するためのチームが存在します。「チーム」となっていますが、今のところ私一人です。 今回は、弊社製品のkintoneとオープンソースのnginxによるリバースプロクシを組み合わせて、社内のエンジニアが手軽にHTTPSを使えるようにした話を書きます。 モチベーション 開発者が手元の開発環境でHTTPSを使いたい場面というのは、意外とたくさんあります。以下は、実際に社内であったケースです。 HTTPSでのみ発生する問題を手元で再現させたい 社内システムをHTTPSで運用する必要がある 例1) SAML認証でSSOするためにHTTPSが必須 例2) Service Workerを利用するためにHTTPSが必須 例3) 社内でDocker Registryを運用している
Web over HTTPS DevFest Tokyo 2016 #devfest16 2016/10/0
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にあがっている動画を見れる人は動画を見て貰えれば良いのですが、時間が無いという人のために、その内容をまとめました。基本的には文字起こしに近い
この脆弱性の対応策がNetwork Secure Config機能に入っています。 宣伝になりますが、ちなみに、この脆弱性はRiskFinderでも検知ができ以下のようなメッセージが表示されます。 脆弱性が生み出される理由 さて、これらの脆弱性が生み出される理由は、何かというと、凡ミス、及び知っているか知っていないかの単純な知識不足です。 アンドロイドアプリの多くは、サーバと通信をします。ログイン等の処理があるときはhttpsを使用して通信を行います。しかしながら開発段階では、サーバの正式な証明書は用意されていません（正式なサーバ名も決まるのは、開発の最後の段階だったり、開発が終わってからだったりしますしね）。従って開発段階では、テストサーバを立てて開発を行います。テストサーバとhttps通信を行うとき、もちろんサーバー証明書が必要になりますが、パブリックCA局にお願いしてお金を払ってテス
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 OWASP Night 8thに行ってきて、iOSやAndroidのいろんなアプリのHTTPS接続の検証がいい加減という話を聞いてきたんですが、それよりもAndroidのデフォルトブラウザChromeが失効検証をしない(=証明書の取り消し確認をしない)という事だって十分問題なんじゃないかなぁとか思ったりしてました。 そういえば以前、秋山さんにAndroidだとHTTPS通信がRC4-MD5になっちゃうという話を聞いて、実際にAndroid上のChromeやOperaやFireFoxを見て全く問題ないことを確認し「よしよし安心だ」などと思っていました。 あれれ?待てよ、秋山さんが言っていたのはブラウザではなく、APIで呼び出したときのCiphe
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 を前進させる手段である
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
