Let's Encrypt、ルート証明書切り替えに向けて古いAndroidへの対策を呼びかけ 83
ストーリー by headless
対策 部門より
対策 部門より
Let's Encryptがルート証明書の切り替えに向け、古いバージョンのAndroidへの対策をサイトオーナーとユーザーに呼びかけている(Let's Encryptのブログ記事、
The Registerの記事)。
5年前にLet's Encryptが立ち上げられた際にはIdenTrustのクロス署名を得たルート証明書「DST Root X3」を使用することで、メジャーなソフトウェアプラットフォームすべてで信頼される証明書をすぐに発行することが可能だったという。しかし、DST Root X3は2021年9月1日に失効する(ただし、実際に証明書を見ると有効期限は日本時間2021/9/30 23:01:15となっている)。他のCAからクロス署名を得た証明書を使い続けることはリスクが高いため、Let's Encryptでは既に独自のルート証明書「ISRG Root X1」を発行している。このルート証明書はメジャーなソフトウェアプラットフォームから信頼されているが、2016年以降更新されていないソフトウェアには信頼されない。Androidではバージョン7.1.1よりも古いバージョンが該当するとのこと。
Androidは更新されない古いバージョンが多数存在することで知られるが、Android Studioのデータによると9月時点でAndroid 7.1よりも古いバージョンのシェア合計は33.8%(StatCounterの10月分Androidバージョン別シェアデータでは18.87%)だったという。DST Root X3が失効するまでにAndroidの古いバージョンが使われなくなることは期待できないため、Let's Encryptでは早めに情報を提供することでサイトオーナーと古いバージョンのAndroidユーザーに事前の対策を促している。
5年前にLet's Encryptが立ち上げられた際にはIdenTrustのクロス署名を得たルート証明書「DST Root X3」を使用することで、メジャーなソフトウェアプラットフォームすべてで信頼される証明書をすぐに発行することが可能だったという。しかし、DST Root X3は2021年9月1日に失効する(ただし、実際に証明書を見ると有効期限は日本時間2021/9/30 23:01:15となっている)。他のCAからクロス署名を得た証明書を使い続けることはリスクが高いため、Let's Encryptでは既に独自のルート証明書「ISRG Root X1」を発行している。このルート証明書はメジャーなソフトウェアプラットフォームから信頼されているが、2016年以降更新されていないソフトウェアには信頼されない。Androidではバージョン7.1.1よりも古いバージョンが該当するとのこと。
Androidは更新されない古いバージョンが多数存在することで知られるが、Android Studioのデータによると9月時点でAndroid 7.1よりも古いバージョンのシェア合計は33.8%(StatCounterの10月分Androidバージョン別シェアデータでは18.87%)だったという。DST Root X3が失効するまでにAndroidの古いバージョンが使われなくなることは期待できないため、Let's Encryptでは早めに情報を提供することでサイトオーナーと古いバージョンのAndroidユーザーに事前の対策を促している。
ユーザーは使用しているAndroidのバージョンが5.0(Lollipop)以降であれば、Firefoxを使用することで証明書エラーの問題を解決できる。FirefoxはISRG Root X1を信頼しているため、AndroidバージョンにかかわらずLet's Encryptの証明書を使用するサイトで証明書エラーが表示されることはない。ただし、Android 4.4 KitKat以前のバージョンも2%前後のシェアがあり、現在使われているすべてのAndroidバージョンをカバーすることはできない。Googleが昨年Android 10にデザートの名前を付けないことを発表した際、Androidのアクティブデバイスが25億台に達したと述べていたので、5千万台前後が残されることになる。
また、Let's Encryptでは2021年1月11日にISDG Root X1移行に向けたAPI変更を計画しているが、オプションでDST Root X3を用いることも可能になるという。ホスティングプロバイダーを通じてLet's Encryptの証明書を利用している場合、すぐにISRG Root X1へ切り替えるか、DST Root X3を失効まで使い続けるかはホスティングプロバイダー次第となる。そのため、不明な点はホスティングプロバイダーに問い合わせる必要がある。
DST Root X3を使い続けることで、サイトオーナーは2021年9月1日まで証明書の問題を先送りできるが、長期的な解決にはならない。対策としては、古いバージョンのAndroidユーザーに対してFirefoxの使用を推奨するバナーを表示したり、HTTPにフォールバックしたりするほか、Let's Encryptの使用をやめて古いバージョンでも信頼されるCAに変更するといった対策が挙げられている。
日本では全体の 3% ぐらいのシェアなのでは? (スコア:5, 参考になる)
Android Studioのデータによると9月時点でAndroid 7.1よりも古いバージョンのシェア合計は33.8%
とのことだが、自分のサイト(エンタメ系ブログ)のGoogleアナリティクスでは n = 627,669 で 9.68% しかなかった。
そもそも、Androidの割合が32.91%しかないので、全体(PCやiPhoneも含む全体を分母とした場合)からすると、僅か 3.18% だ。
[ISRG Root X1 が利用可能な Android 7.1.1 以降の割合]
分母: Android デバイス利用者のセッション
期間: 2020-10-01 - 2020-10-31
セッション数: 627,669
セッション持続時間: 30分間 (最後のアクセスから30分以内の次ページアクセスは1セッションに含み新たなセッションとしない)
11 : 0.41%
10 : 56.33%
9 : 20.15%
8.1.0 : 0.93%
8.0.0 : 12.19%
7.1.2 : 0.31%
合計 : 90.32%
7.1.0 以下のAndroid : 9.68%(バージョンがばらけまくってて全部足すのが面倒なので全体から7.1.2以上を引いて計算した)
分母 = Android デバイスが全体に占める割合: 32.91%
影響: 32.91% * 9.68% = 3.18%
Android利用者の割合を調べる上での注意として、ユーザーではなくセッション でデータを見る必要あり。
(最近のiPhoneのSafariはGoogleアナリティクスのトラッキングCookieを勝手に定期的に消すプライバシー機能があるので、新しいユーザーと認識されてiPhoneのユーザーの割合が異常に高くなる)
自分のサイトとAndroid Studioのデータで3倍もの違いがあるのは驚きであるが、サンプル数は十分にあるので「世界」と「日本」の違いが大きいと思われる。
一応なんだかんだで、日本は世界3位のGDPの国なので、それなりにスマホ端末にお金をかけて買い替えているのかもしれない。
また、恐らく、「世界」では日本と違って2年ごとに端末を買い替えないと実質損する制度があまり普及しておらず、古いAndroidの買い替えが進んでいなかったのではないだろうか。
2021/9/30 まではまだ1年弱あり、3~4割は買い替えるだろうから、この3%というデータは更に少なくなって、2%とかそのへんまで落ちるであろう。
とはいっても、2%というのは無視できる数値ではない。
導入コストや人件費を無視して単純計算した場合、7.1.0 以下のAndroidに対応している証明書が年1000円で買えるので、年5万円以上稼いでいるサイトなら有料の証明書を買った方が得ということになる。
ジャンルによって利用者の端末の傾向が違うかもしれないので、自分のサイトのアクセス解析をみてみるとよいだろう。
Re: (スコア:0)
Androidの割合が32.91%しかないので、全体(PCやiPhoneも含む全体を分母とした場合)からすると、僅か 3.18% だ。
個人サイトだとどうでもいいと判断されますが
ショッピングサイトですと
コンバージョンも鑑みいくらの損失になるか
という判断になりますので
判断権限のある方の考えによっては
僅かでも損失が出ることは許されない
てかもっと緩くして稼げ
ってことになりかねないかと
もちろんそれによるデメリットやコストには耳を塞ぐ形で
# 重要なのは感情だという管理職の方が多かったりするのはフィクションの世界だけじゃなかったり
Re: (スコア:0)
ショッピングサイトですと
コンバージョンも鑑みいくらの損失になるか
という判断になりますので
を検討するまでもなく
7.1.0 以下のAndroidに対応している証明書が年1000円で買えるので、年5万円以上稼いでいるサイトなら有料の証明書を買った方が得
の方で終了な気がする
1年ごとに証明書入れ替える人件費を考えても、Let's Encryptの更新スクリプトが正常に動作しているか監視(手動、もしくはそのためのスクリプトの作成)するコストも必要だし、沢山のサーバを管理しているサーバ屋さんとかでない限り有償証明書の方が優位なんじゃないかな。
CertbotクライアントもPythonのバージョン等に依存するし大胆なアップデートを繰り返すなど安定している状況にはないから、1年後にも今のまま設定等一切弄らず動く保証も何もなく情報収集コストもかかる。
Re:日本では全体の 3% ぐらいのシェアなのでは? (スコア:1)
dehydrated はいいぞ (小声)
https://github.com/dehydrated-io/dehydrated [github.com]
まあサーバ証明書有効期限を必要以上に縮めていこうとする連中の息の根を止めるのが先だよな
ユーザーが自分でISRG Root X1をインストールすれば (スコア:0)
よいのでは?
Re:ユーザーが自分でISRG Root X1をインストールすれば (スコア:1)
androidって全機種でルート証明書インストール可能なのかな?
昔オレオレ証明書を入れようとしてどうしても成功しなかった記憶がある
Gingerbread/HoneycombかICSの頃の話だけど。
Re:ユーザーが自分でISRG Root X1をインストールすれば (スコア:1)
前回のストーリーで既出のやりとり。
端末側の証明書を更新すれば? (#3868695) | Let's Encrypt証明書を使用しているWebサイト、Android 7.1以前の端末での閲覧に影響か | スラド [srad.jp]
システムのルート証明書ストアとユーザのルート証明書ストアに分かれていて、後者はroot権限なくても自由にインストール可能。
ただし、画面ロック「なし」「スワイプ」との両立ができないという訳のわからない仕様。あと起動時に毎回警告が出るようになる。
現実的にはGoogle Play開発者サービス側でシステムの証明書を自動更新するしかないと思うし、そうすべきだと思う。
素晴らしい設計だと思うが (スコア:5, 参考になる)
ただし、画面ロック「なし」「スワイプ」との両立ができないという訳のわからない仕様。あと起動時に毎回警告が出るようになる。
ルート証明書をインストールすれば、例えば、自宅内に全ての通信を中継するプロキシサーバ的なものをたてて、大手メールサービスのサーバになりしまして本物と中継することができてしまう。
つまりは、息子・娘・配偶者のメール等のやり取りを監視することだってできてしまうのだよ。
ロック無しのスマホだったら勝手に第三者がX.509ルート証明書をインストールできてしまうでしょ。
だから、ロック無しのスマホにはそもそも独自のルート証明書をインストールできないようにするのが正解。
警告が出るようにするのも、万が一PINの盗み見などで不正にルート証明書を第三者がインストールした場合に知ることができるために必要。
この必要性が理解できないような人は、ルート証明書のインストールなんて危険なことはしない方が良い。
偽サイトから偽のルート証明書をインストールしかねない。
Re:素晴らしい設計だと思うが (スコア:2, 参考になる)
↑これは真
↑これは偽
この叙述トリックをモデレータが見破れずに #3920626 が (スコア:4, 参考になる) となっているのが悲しい。
ロック無しのスマホに独自のルート証明書をインストールできないようにしたところで、第三者は勝手にロックを設定して独自のルート証明書をインストールできてしまうので、そもそも対策になっていない。
(厳密には、次回ロックされた場合に本来の利用者が解除できず被害の拡大を防げることもあるけど、それについても抜け道があったりするので割愛)
第三者が勝手にルート証明書を閲覧したりアンインストールしてしまうことが防げるだけ。そこには何の意味もない。
Re:素晴らしい設計だと思うが (スコア:1)
うわぁ……問題を理解してない教科書テンプレ回答のマジレスきちゃった。
継続的な侵害防止のため警告表示は妥当だけど、画面ロックとkeychainが連動する必要は一切ない。
この仕様はAndroidが画面ロックのPINをkeychainの暗号化に使い回してる設計の悪さ故の制約。
LinuxもMac OSもログインパスワードとkeychainのパスワードは別に設定できる。
そもそもkeychainの暗号化は認証情報の漏洩による侵害の拡大を防ぐためのものなので、秘密鍵を含まないルート証明書は暗号化して保存する必要すらない。
セキュリティのためと偽って必要のない不便を強いるのは害悪でしかない。
Re: (スコア:0)
VPNでも同様の挙動になるので、エンプラ向け機能を使うときは画面ロック「なし」「スワイプ」が使えないみたい。
ユーザの積極的対応は期待できない (スコア:0)
ので、うちではLet's Encryptを使うのやめました。
予算だけ確保して、より具体的な日程が分かってから、
その日程に合わせてもうちょっとマシな証明書を買う予定。
Re: (スコア:0)
有効期限1年の証明書しか使えなくなったので、自動更新できないCAは使う気になれない。
管理サーバ数が数十ぐらいだったら、「手動更新」の方が良い (スコア:1)
そもそも、サーバというのは、リソースやディスクI/Oの急変だの急に吐かれたエラーログやら数秒に1回のサービス動作チェックへの応答がないときの対応やらその他で24時間体制で監視・対応するもの
(それができないなら、できる業者にroot持たせた方が良い)
1年に1回の更新を手動でやったとして、サーバ1台管理する手間に加わる割合なんて微々たるものでしょ
手動の場合は、
・11ヵ月に1回の更新タスクを職場の共有スケジューラー等にスケジュール
・普通にサーバ証明書をチェックして Not After まで1か月切ったら警告する管理スクリプトの作成
などの対応をして、1年に1回手動で更新すればいい
Let's Encrypt で自動更新している人、本当に安全な方法で出来てる?
公式サイトは勿論、あちこちの情報サイト見ても、毎秒数百以上のアクセスがあるようなWebサーバで安全に更新できるようなスクリプトは全く見かけない
certbot certonly --webroot -w /home/www/www.example.com --noninteractive --post-hook "systemctl reload httpd.service" のような方法での解説、よく見かけるけど、
まずユーザーの端末の時計が数分狂っていたりタイムゾーンがずれていたりなんてこと(特に海外では)はよくあることなので Not Before 前の証明書扱いでエラーになるわけで
新たに取得した証明書は2~3日は寝かした方が良い
ユーザーの端末の時刻やタイムゾーン設定が絶対に合っている仮定しても、FirefoxだとOCSPが反映される数分間はエラー扱いになることが多いので、最低でも10分は待たないと駄目
そして、毎秒数百以上アクセスがあるようなWebサーバーだと再起動で少しでも負荷があがると直後の負荷が心配だから何かあったとき有人で対応できるときじゃないとリロードなんてすべきではない。
極端な話、スマートニュースやYahoo!ニューストップにサイトが掲載されたなどで急激なトラフィックが生じて負荷がぎりぎりのときにreload走ったら困るでしょ。
AWSのAuto Scalingだって急激なトラフィック急増には対応できないってのに
ってことで、サーバーのリロードは負荷状態が問題ないことを確かめたタイミング、かつ深夜などの影響が少ない時間帯、かつ有人で即座に人が対応できる状態でやるべき
負荷状況といっても、データベース負荷とか現在のコネクション数とか帯域とか色々見るところあるからなかなか自動化は難しい
Webサーバーのレスポンスが1~2秒遅延しただけで、いっきにDBサーバにまとまってSQLクエリが流れて、そこで過負荷でトラブルなんてこともよくある
Webサーバーのreloadっていうのは結構危険な作業だったりする
ってことで色々考えると、管理しているサーバの台数が数十やそこらだったら、変に自動化せずに手動でやったほうがトータルで良いと思われる
それでも、どうしても自動化したいならば、証明書の更新を自動化できるとこなんてCAなんて山のようにある
国内だと https://www.fujissl.jp/fujissl-go/ [fujissl.jp] とか
日本は古い体制のところが多いけど、海外含めればむしろ大手で自動化に対応できていないとこの方が少ないぐらい
Re:管理サーバ数が数十ぐらいだったら、「手動更新」の方が良い (スコア:2, 参考になる)
などの対応をして、1年に1回手動で更新すればいい
そうは言うけど、こういう話もあって、いつか有効期限1年の証明書も出なくなるかもしれない。
何度も短縮し過ぎ?!SSL証明書の有効期間がどんどん短くなる理由とは? [sakura.ad.jp]
なお、自分の場合、今のところ1年に1回手動で更新している。会社指定のCAを使わないといけないので、自動化できるかどうかはそこ次第。
OCSPレスポンダ (スコア:1)
FirefoxだとOCSPが反映される数分間はエラー扱いになることが多いので、最低でも10分は待たないと駄目
ググったら、
https://help.sakura.ad.jp/360000143762/ [sakura.ad.jp]
JPRS社のSSL証明書は、OCSPレスポンダにSSL証明書の情報が登録されるまでに最大30分程度かかる場合があります。
このため、SSL証明書が発行された直後はOCSPによる失効情報の検証ができず、有効なSSL証明書として認識されないため、サイト閲覧時にエラーが出る可能性があります。
OCSPに対応しているブラウザをご利用の場合、SSL証明書発行直後は正常にサイトが閲覧できない可能性があります。
また、ブラウザのキャッシュにより1度アクセスすると最大6時間程度アクセスできない可能性があります。
だそうだが、Let's Encryptの情報は出てこなかった。
Let's Encryptだと最大何分?
Re:OCSPレスポンダ (スコア:1)
仮に CDN でキャッシュ機能があるとしてもサーバーに設定して証明書を使い始めるまでは OCSP リクエストがされることはないので、レスポンスがキャッシュされてしまうことはないと思います。
Let's Encrypt は、証明書を発行してから OCSP データベースに反映するまでのタイムラグもほぼゼロじゃないでしょうか。発行後すぐにレスポンスが返ってきそうです。
新規発行でも OCSPへの反映に 30 分もかかるのは遅くないですか? CRL と中途半端に統合していてバッチ的に処理がなされているのでは?
Re: (スコア:0)
場末のショボいレンタル web サーバを手動更新してるけど、そんな大規模な人気サイトじゃないから、気にせず reload しちゃってるわw
というか、たぶん永久にそうならないけど、人気出たら CDN に肩代わりしてもらおうと思ってました。
負荷が高いサーバだと、考えることがたくさんあるのですね。
ところで、 CDN を使えば、オリジンサーバにはそこまで心配しないでもいいような気がしますが、別に考慮しなくちゃいけないこと出てきたりするのでしょうか。
Re: (スコア:0)
無料なところはともかく、有料のSSL証明書発行してるところは、
顧客のWebサイトの証明書を監視して、期限が近づくと警告するサービスをやればいのに
2か月前でメール警告、1か月前で再度メール警告、2週間前にメール&電話&手紙の両方で警告、みたいな
Re: (スコア:0)
Re:管理サーバ数が数十ぐらいだったら、「手動更新」の方が良い (スコア:1)
エンジニアは自動化すること自体が仕事じゃないの?
単なる作業員なら学生アルバイトでいいわ。
Re: (スコア:0)
自分だけかもしれないけど、多少自動化で手間減らしたくらいでは「自分の存在自体が不要になる」にはならないと信じている。
それでも運良く(運悪く?)自分の首を絞めるほどなんでもかんでも自動化できてしまったら、異動するなり時機を見て転職するなりするよ。そのとき、職場に未練なんか残っているわけがないだろうから。
Re:管理サーバ数が数十ぐらいだったら、「手動更新」の方が良い (スコア:1)
エクセルマクロ作ってルーティンを自動化したら、その部署の人員半分にされたとかはよく聞く話だけど、
仮にもエンジニアであるならば自動化もできない人の方が首切られて終わるかも。
Re: (スコア:0)
むかしの大企業や金融機関には、そろばんができる多数の経理担当社員(ほとんど女)がいた
コンピュータ化によりそれらの仕事がなくなった
それでも昭和時代はかわりの職があったが、平成時代になってからかわりの職がなくなった
平成になってから、中小企業でも経理担当社員の数は大幅に減った
Re:管理サーバ数が数十ぐらいだったら、「手動更新」の方が良い (スコア:1)
それが computer なわけですが
Re: (スコア:0)
Let's Encrypt以外で自動更新できるCAのおすすめありますか?
# ローバラかませてると対応難しいですが
# 全部CDN任せにしちゃうのが簡単そう
Re: (スコア:0)
ドメイン証明のみなら、自動更新で可能でも、
組織の実在証明とか、EV SSL証明が必要な金融業界や、大手通販サイトでは、
自動更新できないCAが必要になるのでは?
Re: (スコア:0)
ニュースサイトとかそういうのだと、見れるところに流れていくだろうし、
ゲームなら古いAndroid切れる絶好の機会だったり?(有料コンテンツ利用率は低そうだし)
どういうユーザーかとユーザーとの関係にもよるのでしょうね。
良い機会 (スコア:0, すばらしい洞察)
Android 7.1よりも古いバージョンなんて
ネットに繋がっている事自体が害悪ですので
Let's Encryptだけでなくむしろ
全ての証明書で同様の事態になったほうがいいですね
証明書だけ対応させる裏技なんてのももってのほか
買い替えかROM焼きできっちりセキュアに使う義務を
ユーザー、キャリア、ベンダ全てに課してほしいものです
# そして「あなたの端末は危険」詐欺が大賑わいに
Re: (スコア:0)
根本的に見直すと言うなら、階層型の認証基盤の考え方が古い。
古いと言うか、人類の歴史の中で階層型の信頼関係なんてものがうまく機能したことがあるとも思えん。
Re:良い機会 (スコア:2)
Re: (スコア:0)
根本的に見直すと言うなら
というか
SSL3.0やTLS1.0やTLS1.1のときと同様に
切り捨て前提でいいんじゃないかと
問題は世間の情報取り上げ情況なので
世間への啓蒙努力をもっと頑張ろうで十分かと
Re: (スコア:0)
古いOSが害悪だとか言ってる自称中級者は結構いるが、
OSが古いことによって第三者に迷惑かけることはほとんどない。
ってかボットネットを構成するのは管理の甘いサーバ。
あと今やOSのセキュリティホール狙うのはハードルが高いので
普通はミドルウェアを狙う。
Re:良い機会 (スコア:1, すばらしい洞察)
古いOSが害悪だとか言ってる自称中級者は結構いるが、
OSが古いことによって第三者に迷惑かけることはほとんどない。
ってかボットネットを構成するのは管理の甘いサーバ。
あと今やOSのセキュリティホール狙うのはハードルが高いので
普通はミドルウェアを狙う。
この手の主張をする阿呆が未だに絶えないのは確かに問題だな
Re: (スコア:0)
月例パッチが数か月どころか下手したら年単位にあたっていないAndroidは山のようにある
世界でいえば下手したらAndroidの半数以上がまともにパッチあてされていないんじゃないかな
そんな脆弱なAndroidにみんなは銀行アプリ(世界では通帳無しが常識だからアプリがないと明細すらまともに見れない)も何もかも入れて使っているけど大きな問題は起きていない
世の中に何億と脆弱なAndroid端末があるのに、日常でAndroidスマホのrootが乗っ取られて訳の分からないアプリがインストールされたとか何もしていないのにロック画面に広告が表示されるようになったとか、そういう被害に遭う人は居ない訳ではないが極わずか
デジタルガジェットのセキュリティにうるさい人でも、リアルでのセキュリティはガバガバだったりするよね
在宅時にピッキングで侵入してちょっとナイフ突き付けて左手の指でも折って脅せばパスワードマネージャーのマスターパスワードすらしゃべりそう(笑)
日本でもそういう手口でビットコイン強盗が既に行われているのだよ
Re: (スコア:0)
古いスマホをwifi運用して、ベッドや風呂で使ったりしてる人は多いのでは?
寝落ちしてバッテリ干上がっても、wifi運用のサブ端末なら安心
Re:良い機会 (スコア:1)
消費期限切れの弁当と比較してどっちが良い?
Re:良い機会 (スコア:1)
オープンソース全否定ワロタ
あれ? (スコア:0)
サイト証明書のチェックって
ブラウザのお仕事かと思っていましたが
OSのお仕事だったんでしょうか?
ストアのGoogle chromeの自動アップデートで古いAndroidでも
サイト証明書のチェックは可能かと思いましたが
Google chromeのサポートが
Android 7.1以下をサポートしないってことなんでしょうか?
FirefoxはAndroid5.0でも問題でないみたいですし
それともAndroid Webviewが更新されないために
Android Webviewを利用するアプリで
Let's Encrypt証明書のサイトへの接続エラーが出ますよ
ということなのでしょうか?
それならお店アプリで問題がという話で頷けます
Android Webviewの更新状況次第で
接続エラーが出るアプリが出るよ
ということでいいのかな?
OSの証明書ストアを使っているブラウザのみに影響 (スコア:1)
問題になるのは、標準ブラウザ・Android Webviewを使ったブラウザアプリ・OSのストアを使っているGoogle Chrome だけ。
Firefoxは独自の証明書ストアを使っているので全く問題ない。
といっても、ストアまで独自で持っているのはFirefoxぐらいだから、Firefox以外の全ブラウザに影響するといえる。
Re:あれ? (スコア:1)
ブラウザの作りによる
基本的に最近のOSはSSL/証明書関連のAPIが整備されており、それ使えばOSまかせに出来る
FirefoxはOSに頼らずに自前でやる
Re: (スコア:0)
サイト証明書をチェックするのはブラウザのお仕事。
サイト証明書のチェックにはルート証明書が必要。
ルート証明書の管理・更新は基本的にOSの仕事。
Re: (スコア:0)
>ルート証明書の管理・更新は基本的にOSの仕事。
現在の主流はそうなんですが、本来はOSの仕事ではないです
あくまでもHTTPSを必要とするシステムが行うべきものです
Re:あれ? (スコア:1)
そんなことを言い出したらスマホのAPIの9割は「OSの仕事」ではない
つまりOSの仕事という言葉の意味がスマホとパソコンでは全く異なる
Re:あれ? (スコア:1)
Re: (スコア:0)
とはいってもHTTPSを使うものが増えた今となっては、個別にルート証明書を管理するのがいいやり方だとは思えないな
Re: (スコア:0)
サイト証明書が信頼できるかどうかの確認には最終的にルート証明書が必要。
> 他のCAからクロス署名を得た証明書を使い続けることはリスクが高い
となると新たなルート証明書の取得を自動で行うのはなりすましの可能性を排除できないので
自力で信頼できる証明書を入手して手動でインストールするか、OSに最初から組み込まれているルート証明書を使うしかない。
「どうやって信頼できる形でルート証明書の更新を行うか」は古くからの問題で、完全な解決策と言えるものはないみたい
関連ストーリーに出てるけど (スコア:0)
https://srad.jp/story/20/08/11/0411203/ [srad.jp]
公式に告知されたってだけで話自体はとくに新しいものじゃないよね?
Re: (スコア:0)
ていうかほとんど同じ議論をボケ老人のように繰り返していてさすが老人会…ってなった
実際「インターネット老人会」だからね (スコア:0)
昔は、スラドをインターネット老人会扱いするのはただの自虐ネタだったんだけど、
今では本当にインターネット老人会になっているので笑えなくなっている。
IT系の職場にいるなら新入社員にでも聞いてみると良い。
「スラドってサイト知ってる?」って
数十人新入社員居ても誰一人知らないなんて状況だろうな。
スラド・はてブ・GIGAZINEあたりは本当に老人向けサイトなのが実情なので、それらのサイトを見ている人は注意した方がいい。
そういったサイトばっかり見ていると、若い人の話題についていけなくなる。