Intro ついに URL バーから EV 証明書の組織表示が消されるアナウンスが、Chrome から発表された。 思えば、URL バーの見た目も、だいぶ変わってきたように思う。 URL バーの表示の変遷を一度まとめておく。 URL バーの再現 本当なら古いブラウザのスクショを集めたいところだったが、これは非常に難しい。ネットで色々落ちてるものをかき集めても、ライセンスや解像度や表示されている URL などを考えると、使い勝手は決して良くない。 試しに古い Chromium をビルドしてみたが、一定より古いものはうまく開くことすらできなかった。開くことができたバージョンもあったが、どうやらそれだけでは当時の URL バーの UI までは再現されないようだ。 そこで、実物のスクショはあきらめ「一般的な URL バーのイメージ」を書いた図で、おおまかな変遷を辿る。あくまで架空の図であることに注
TLS 1.2 to become the minimum TLS protocol level for all AWS API endpoints | Amazon Web Services
AWS Security Blog TLS 1.2 to become the minimum TLS protocol level for all AWS API endpoints February 27, 2024: AWS has completed our global updates to deprecate support for TLS 1.0 and TLS 1.1 versions on our AWS service API endpoints across each of our AWS Regions and Availability Zones. January 17, 2024: Over 96% of AWS service API endpoints have ended support for TLS versions 1.0 and 1.1. Over
こんにちは id:cohalz です。はてなブログでは2021年4月の公式ブログで、すべてのブログをHTTPSに一本化していくことを案内しました。 ▶ 「HTTPS配信」への切り替えと、ブログの表示の確認をお願いいたします この時点でまだ数百万件のHTTPのブログが残っている状態でしたが、2021年8月には上記の案内に追記したように、全ブログでHTTPS化を完了できました。 完了までに行ってきたことをこの記事で振り返ってみようと思います。 はてなブログのHTTPS化のこれまで はてなブログのHTTPS化は、2017年9月に最初のお知らせを行ってスタートしました。 当初の予定より時間がかかりましたが、2018年2月にHTTPS配信の提供を開始し、これ以降に作成されたブログは最初からHTTPSのみで配信されています。また、それ以前に作成されたブログでも、ユーザ側で設定を変更することで自分のブロ
大分銀行ビジネスダイレクト（法人向けインターネットバンキング）でMicrosoft Edgeを利用した電子証明書ログインができない事象について 2021年9月3日（2021年9月6日更新） 現在、Microsoft Edgeを利用して大分銀行ビジネスダイレクトに電子証明書でログインできない事象が発生しております。 なお、電子証明書をご利用でないお客さまは影響ありません。 お客さまにはご不便をおかけいたしますが、何卒ご理解いただきますようお願い申しあげます。 ＜2021年9月6日 17：00追記＞ Microsoft Edgeのバージョンアップにより、操作手順が一部変更となりました。 電子証明書でのログインの際に、「認証用の証明書の選択」ダイアログが表示されますので、該当の証明書をクリックして選択のうえ、「ＯＫ」ボタンを押して、ログインしてください。 上記の方法で電子証明書でのログインがエラ
SRE 兼よろず屋の id:sora_h です。最近は本社移転プロジェクトをやっています。趣味は Web *1 です。 さて、クックパッドでは 2020 年 12 月に TLS 1.0 および TLS 1.1 (以後 "Legacy TLS") を廃止しました。 Legacy TLS は RFC 7457 でまとめられているような既知の脆弱性の存在などから、Chrome, Firefox といった主要ブラウザを含め各所でのサポートが打ち切られつつあります。また、現在では IETF においても Legacy TLS は deprecated と RFC 8996 にて宣言されました。 クックパッドでもセキュリティ対策およびレガシーな技術と向き合う一環で廃止を進めました。我々は歴史の長いサービスも提供しているため、古い Android や Internet Explorer などからのアクセス
Most of the time, http://localhost behaves like HTTPS for development purposes. However, there are some special cases, such as custom hostnames or using secure cookies across browsers, where you need to explicitly set up your development site to behave like HTTPS to accurately represent how your site works in production. (If your production website doesn't use HTTPS, make it a priority to switch t
「Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる」の続き。 色々動きがあって猶予もできて助かった形だけど、来年9月29日以降の対応をどうするか考えないといけない状況なのは当然変わっていません。先にまとめると以下。 何もせずとも来年の1月11日までは猶予が伸びた 証明書を発行する側の場合、各クライアントで --preferred-chain "DST Root CA X3" のようにオプション設定することで、来年の9/29まで先延ばしが可能 独自ドメインに対して自動でSSL証明書を発行してくれるサービスを利用している場合はサービスが声明を出していないか調べ、出してない場合は問い合わせると良いでしょう 前回以降の動き go-acme/legoに--preferred-chainオプションのpull requestを取り込んでもらいました デフォルトRoot証
We intend to update Mozilla’s Root Store Policy to reduce the maximum lifetime of TLS certificates from 825 days to 398 days, with the aim of protecting our user’s HTTPS connections. Many reasons for reducing the lifetime of certificates have been provided and summarized in the CA/Browser Forum’s Ballot SC22. Here are Mozilla’s top three reasons for supporting this change. 1. Agility Certificates
今後Safariで起きること Safariとは、Appleで開発されているWebブラウザであり、パソコンであるMacの他にiPhoneやiPad、Apple TV、Apple Watchなどの端末に標準で搭載されています。 このSafariにおいて、2020年9月1日以降に発行された「有効期間が399日以上」のSSLサーバー証明書（以下、SSL証明書）が信頼されないことになります。 具体的なエラー画面の仕様などは明らかにされていませんが、Appleの発表に「This might cause network and app failures and prevent websites from loading.」と書かれていることから、失効したSSL証明書を利用しているサイトにアクセスした時のように、全画面でエラーが表示されてサイトへはアクセスできなくなってしまうことが考えられます。 購入済み
信頼済み証明書に関する今後の制限について Apple では、お客様の利益向上のため、Web のセキュリティ向上に日々努めています。その一環として、TLS サーバ 証明書の最大有効期間を短縮します。 変更点 2020 年 9 月 1 日 00:00 (GMT/UTCTLS) 以降に発行されたサーバ証明書は、有効期間が 398 日間を超えないものとします。 今回の変更は、iOS、iPadOS、macOS、watchOS、tvOS でプレインストールされるルート CA が発行する TLS サーバ 証明書にのみ適用されます。また、2020 年 9 月 1 日以降に発行される TLS サーバ 証明書にのみ適用され、その日付以前に発行された証明書は、今回の変更の影響を受けません。 こうした新しい要件に違反する TLS サーバへの接続は、認められなくなります。その結果、ネットワークや App が機能しな
はじめに 以前の記事DNS over HTTPSの必要性についてで触れたEncrypted SNIについて、その有効性と現在韓国で行われているSNIフィールドを利用したブロッキングを回避する方法についての説明です。 Encrypted SNIとは Encrypted SNIは、現在広く使われているTLS1.2以下のハンドシェイク時、接続したいドメインが「平文」で流れ、盗聴による接続先の推測やブロッキングが行われてしまうという問題を解決するための手法です。Encrypted SNIの手法については当初の案と現在Cloudflare社がサービスを運用している案で大きく異なるため、簡単に説明します。 トンネリング方式 TLS接続時に、まず中継サーバへTLS接続し、そのTLSコネクションの中で目的のドメインまでTLS接続を行う方式です。"TLS in TLS"と呼ばれています。 TLS 1.3 E
[Edit September 2020: I’ve updated the change date in this post to refer to the current plan, to make it easier to find] We’re going to delay the transition to ISRG’s root a little further, to January 11 2021. The patterns of Android adoption have not significantly improved since last year. According to numbers from Android Studio, only 66% of Android users are on version 7.1 or above, which inclu
追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う場
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
