HTTPS 証明書クロニクル | blog.jxck.io
Intro Web サービスをデプロイする際に、CA から証明書を取得し HTTPS で暗号化するのが一般的となった。 かつては "SSL 証明書" として、メールでやり取りし有料で購入するのが常識だったが、自動/無料で取得することが増えた。かつては 5~10 年あった有効期限もどんどん短くなり、今では 6 日の証明書も発行されている。 このように、証明書を取り巻く変遷は目覚ましく、それは Web を取り巻く環境の劇的な変化を色濃く反映した結果と言える。 http:// が https:// になった裏で何が起こり、これからどうなっていくのか。まとめていく。 (極力ソースを付記するが、既に消えて WebArchive にも残っていないものも多く、筆者の記憶に頼る情報も多い。) 黎明期 (90 年代後半~2010 年頃) 90 年代の終わり頃、当時は TLS の前身にあたる SSL のデプロ
Your API Shouldn't Redirect HTTP to HTTPS
TL;DR: Instead of redirecting API calls from HTTP to HTTPS, make the failure visible. Either disable the HTTP interface altogether, or return a clear HTTP error response and revoke API keys sent over the unencrypted connection. Unfortunately, many well-known API providers don't currently do so. Updates 2024-05-24: Added the Google Bug Hunter Team response to the report that the VirusTotal API resp
HTTPSは安全なのか？ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? いきなり追記 2024-01-09 この記事にはまともな結論がありませんし論点も定まっていません この記事には批判が多いので、こちらの素敵な記事をぜひお読みください。 Free Wi-Fi(00000JAPAN)は安全なのか？ コメントで不愉快とされたところを削除しました。 徳丸さんのツイート 猫の写真 素人というエクスキューズ （編集履歴はqiitaの機能で見れると思います） 信頼できるサービスであれば Free Wi-Fi に限らず被害に遭う可能性はとても低いと思います。気にせず使ってください。 気分を害された方にお詫び申し上げます
オレオレ証明書を使い続ける上場企業をまとめてみた - megamouthの葬列
あるいは私たちがPKIについて説明し続けなければいけない理由 Web屋のなくならない仕事の一つに「SSL証明書とPKIについて説明する」というのがある。 世の中のサイトはだいたいhttps://というアドレスでつながるように出来ていて、httpsでつながるということは何らかのSSL/TLS証明書が必要だということだ。（さもなければchromeがユーザーに不吉な警告を発することになる） 証明書が必要になる度、同じ質問が繰り返される。「なんか全部値段が違うけど、どの証明書（ブランド）がいいの？」と。そして私たちは毎回困ってしまう。 エンドユーザーの立場で言えば、証明書が有効でありさえすれば、無料のLet's Encryptでも21万円するDigiCertグローバル・サーバID EVでも、Webサイトの利便性は何も変わらない。私たちWeb制作業者の立場でも、代理店契約でもしない限り、証明書そのも
GPKIよ、おととい来やがれ！(タイトルで煽るスタイル) - yumetodoの旅とプログラミングとかの記録
はじめに 煽っておいてすみません。ぶっちゃけGPKIよくわかってないです。 一応 GPKIとはなにか？ - IT digitalforensic.jp の内容が理解できる程度にはわかっているつもりですが。 前提知識 誰がどんな立場にいるかわからんと全くわからんと思うので CA/Policy Participants - MozillaWiki 問題 アプリケーション認証局２(Sub) | 政府認証基盤(GPKI)のホームページ にもあるように、 https://www.gpki.go.jp/selfcert/finger_print.html にアクセスしようとすると のようにルート証明書が信用できんといわれるんですね。 それで、ルート証明書を信用してくれるように mozilla.dev.security.policy › Japan GPKI Root Renewal Request （
Custom domains on GitHub Pages gain support for HTTPS
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか？ 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途
HSTS (HTTP Strict Transport Security) の導入 - Qiita
HTTPで接続した際に、強制的にHTTPSへリダイレクトし、以降のそのドメインへの接続はすべてHTTPSとする機能がHSTS (HTTP Strict Transport Security) である。RFC6797で標準化されている。 これはHTTPヘッダに以下を含むことで実現される。 Strict-Transport-Security:max-age=有効期間秒数;includeSubDomains max-ageではHTTPSで通信する期間を設定する。また、includeSubDomainsを指定することで、サブドメインにもHSTSが適用されるように設定できる。 HSTSのサポートは、2015年6月9日にマイクロソフトがIEへのサポートを追加したことで、すべてのメジャーブラウザにおいてサポートが完了し、HTTPサーバーとしてもApacheを始めとし設定が可能だ。 Apacheの設定 A
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 サーバ(フルレゾルバ)を提供し
エンジニアなら知っておきたい、絵で見てわかるセキュア通信の基本 - Qiita
TLS 1.3は現在策定中ですが、 前方秘匿性 の問題から RSAのみ を用いた鍵委共有が禁止になる見込みです。(詳細は後述します) HTTPSとは 次に、HTTPSです。 HTTPS - Wikipedia HTTPS（Hypertext Transfer Protocol Secure）は、HTTPによる通信を安全に（セキュアに）行うためのプロトコルおよびURIスキームである。 厳密に言えば、HTTPS自体はプロトコルではなく、SSL/TLSプロトコルによって提供される セキュアな接続の上でHTTP通信を行うこと をHTTPSと呼んでいる。 とのことです。 HTTPの説明を割愛するとすれば、「SSL/TLSでセキュアにHTTPをやる」というだけの説明で済んでしまいます。 最近では個人情報等の観点から全てのサイトをHTTPSにするような動きが見られますが、元々HTTPSが使われやすかった
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にあがっている動画を見れる人は動画を見て貰えれば良いのですが、時間が無いという人のために、その内容をまとめました。基本的には文字起こしに近い
HTTP ページ上でのパスワード要求はやめましょう
[これは Mozilla のセキュリティエンジニア Tanvi Vyas 氏のブログ記事 No More Passwords over HTTP, Please! を同氏の許可を得て翻訳したものです] Firefox 46 Developer Edition は、HTTP ページ上でログイン情報の入力を求められた場合、開発者に警告を行います。 ユーザ名とパスワードの組み合わせは、ユーザの個人データへのアクセスを管理する手段です。Web サイトはこうした情報を注意深く扱い、パスワードは HTTPS のような安全な (認証、暗号化された) 接続を通じてのみ要求すべきです。しかし残念なことに、HTTP のような安全でない接続でユーザのパスワードが扱われている例が 非常に多く 見られます。このプライバシーとセキュリティの脆弱性を開発者の皆さんに知らせるため、最新の Firefox Develope
HTTP/2入門
[【セーフィー x ソラコム x ビットキー】IoT基盤のアーキテクチャを中の人が語る会！] ビットキーが語るIoT基盤アーキテクチャとマルチクラウド戦略...
HTML6 でも CSS4 でもない Web 技術のゆくえ - WCAN 2015 Winter に登壇してきました
@kazumich さんにお声がけいただき、WCAN 2015 Winter でおよそ 60 分ほどのセッションを登壇してきました。32:9 のスクリーンがあるという、TED でもやるんかオイという特殊な環境でした。普段はプロジェクター的な投影なので、スクリーンの前に立つのが微妙なんですが、ここはディスプレイが壁面に大量に並んでいて自ら発光するので、部屋を暗くしなくてもテレビのように十分に見えますし前に立っても平気です。 一緒に登壇したのが @yhassy さんと @Hidehisa さんということもあり、近年まれに見る胃痛を伴う緊張を味わいながらお話させていだきました。（リアルにセッション終了後、1時間くらい胃痛がズキズキしてました） 技術的なお話でした 参加されたみなさま、メインセッションや LT に登壇された各位、ならびに運営されたスタッフの方々、ひとまずお疲れさまでございました。貴
meta name="referrer"は、HTTPS→HTTPでもリファラを出す新しい仕様 | 初代編集長ブログ―安田英久 | Web担当者Forum
得意なはずの対人関係で挫折。「全員に好かれなくていい」と気づいたLIFULLマーケターの等身大マネジメント 5月15日 7:05
ブログの完全HTTPS化を完了、HTTPからHTTPSへの移行プロセスを共有
[対象: 上級] 気付いている人もいるかと思いますが、このブログ全体をHTTPSにしました。 この記事では、備忘録を兼ねて、完全HTTPSへの移行を検討しているサイトの参考になるように僕が実行してきたプロセスをまとめます。 実行した主な作業は次のとおりです。 サーバー証明書の取得 HTTPSへのリダイレクト 内部リンクの修正 各種ツール・パーツのHTTPS動作確認 すべてのコンテンツがHTTPSでダウンロードされているかを確認 WordPressの設定変更 rel=”canonical”の更新 ウェブマスターツールへの登録 サイトマップの更新 ソーシャルシェアの引き継ぎ HSTSの設定 外部リンクの更新 高速化 順に説明します。 1. サーバー証明書の取得 サーバー証明書をまず取得します。 手順は利用しているサーバー会社によって変わってきます。 詳しくはお使いのサーバー会社のヘルプを参照し
なぜHTTPSはHTTPより速いのか
先週、httpvshttps.com というウェブサイトが公開されました。このウェブサイトでは、HTTP と HTTPS を用いてアクセスした場合のウェブページのダウンロード完了までにかかる時間の比較ができるのですが、多くの環境で HTTPS の方が HTTP よりも高速なことに驚きの声が上がっていました。 HTTP が TCP 上で平文を送受信するのに対し、HTTPS は TCP 上で TLS (SSL) という暗号化技術を用いて通信を行います。ならば、TLS のオーバーヘッドのぶん HTTPS のほうが遅いはずだ、という予測に反する結果になったのですから、驚くのも無理はありません。 実は、この結果にはからくりがありました。 Google Chrome、Mozilla Firefox、最近のSafari注1は、Google が開発した通信プロトコル「SPDY」に対応しており、HTTPS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TLS徹底演習