ちなみに各省庁、立法、司法の対応状況は、 首相官邸→GlobalSign Root CA 内閣官房→GlobalSign Root CA 内閣府→GlobalSign Root CA 復興庁→ApplicationCA2 Root 総務省→非対応（https指定すると404。ApplicationCA2 Rootを使用） 法務省→非対応（0秒でhttpにリダイレクト。ApplicationCA2 Rootを使用） 外務省→DigiCert Global Root CA 財務省→DigiCert Global Root CA 文科省→非対応（アクセス不能） 厚労省→DigiCert Global Root CA 農水省→非対応（akamai.netに付与された証明書が返ってくる） 経産省→非対応（akamai.netに付与された証明書が返ってくる） 国交省→ApplicationCA2 Root 環境省→GlobalSign Root CA 防衛省→非対応（アクセス不能）
Firefox 64の未翻訳部分 (スコア:3, 興味深い)
Firefox 64日本語版のUIには、英語のままの部分がいくつかある。
どういう経緯でこうなってしまったのかわからないけど(ローカライズにかかわっている皆さんを非難しているわけではありません。いつもありがとうございます)、ベータ版の途中の時期にある締め切りに間に合わないと、次のメジャーバージョンアップまでリリース版の修正はしないルールのよう。
1513259 - ja: Need to localized tab/tabbar context menu
https://bugzilla.mozilla.org/show_bug.cgi?id=1513259 [mozilla.org]
Re:Firefox 64の未翻訳部分 (スコア:3, 興味深い)
オプションの「Recommend Extensions as you browse」なんて、わざと訳さなかったんじゃないかと邪推してしまいます。
デフォルト有効なのがなんとも・・・
CDN業者のSSL証明書 (スコア:1)
最近、既存認証局から委託？を受けて、大手CDN企業が自社名義で他社の証明書を発行してる問題をなんとかしてほしい
最近はフィッシングサイトがSSL証明書つかって営業？してるが、
だいたい大手CDN企業名義で発行された証明書を使ってる
Re: (スコア:0)
そういうもんだから仕方ないのでは。
CDN業者が発行しなくなってもLet's Encryptで取るだけでしょう。
EV証明書とか発行してる？
このへんも関係あるのかな？ (スコア:1)
https://twitter.com/jstage_ej/status/1072773871353311234 [twitter.com]
https://twitter.com/uwabami/status/1073061125762084865 [twitter.com]
Re:このへんも関係あるのかな？ (スコア:1)
J-STAGEがFirefoxでのアクセスを遮断、日本の電子ジャーナルが世界から不可視となった日
https://note.mu/note_s/n/n517ff243e083 [note.mu]
Re: (スコア:0)
証明書入れ替えで設定ミスったのかな？あるっちゃあるのかも。
繋いでみたけどFirefoxで普通に入れたけどな。
Re:このへんも関係あるのかな？ (スコア:4, 参考になる)
いや、cipher suitで(EC)DHE-RSAを使えばいいだけの話。
証明書はRSAのままで鍵交換だけDiffie-Hellman系にするだけ。(証明書は鍵長もsignatureも十分に長いです。CAはDigiCert)
試してみましたが、ECDHE-RSA-AES128などをproposeしてもつながりませんね。
普通につなぐとAES256-GCM-SHA384になる。TLS1.2以上のcipersuitだからECDHEにするのは多分設定だけ。
Re: (スコア:0)
鍵交換でRSAしか受け付けないようになってるからでは？ってリプ付いてるだろ。
だから設定かなって言ってるのに何が「いや」なのかさっぱり。
てかなんで俺のFirefoxは普通に入れるんだ。そこを教えてくれ。
Re:このへんも関係あるのかな？ (スコア:2, 興味深い)
Firefoxの場合 [ssllabs.com]、基本的に鍵交換はECDHEじゃないとダメっぽくて、RSAじゃ受け入れないっぽい。
ただし、互換性のためのTLS_RSA_WITH_AES_256_CBC_SHAが有効になっており、かつJ-stageもそれを再有効化したので(一番弱い方式で)つながるようになったみたいですね。
まぁ、ECDHEを有効にするのが対応としては良いと思いますが、HWでTLS/SSL対応とかしてると、そう簡単には対応できないかな。
Re:このへんも関係あるのかな？ (スコア:1)
てかなんで俺のFirefoxは普通に入れるんだ。そこを教えてくれ。
TLS_RSA_WITH_AES_256_GCM_SHA だった(未確認)のが、
TLS_RSA_WITH_AES_256_CBC_SHA になってつながるようになったみたいです。
https://twitter.com/uwabami/status/1073109389349871616 [twitter.com]
Re: (スコア:0)
証明書の入れ替えじゃなくてTLS1.0/1.1無効化作業での(おそらく見識不足が原因の)ミスだから
「証明書入れ替えで設定ミスった」ではないっていう指摘なんじゃないの？
Re: (スコア:0)
J-STAGE [jst.go.jp]は、現時点では信頼される署名 [ssllabs.com]が適用されているようです。
Firefoxの証明書といえば (スコア:1)
Mozillaが蹴っ飛ばした日本政府の「ApplicationCA2 Root」 [it.srad.jp]が
官報のサイトで使ってる上に、HTTPS必須になったからFirefoxやMozillaのルート証明書群を流用している
スマホでは自分でルート証明書をインストールしなくては見えなくなった。
丁寧に見えない場合の対応方法は書かれてるから
民間が決めたルールを無視して、ユーザーにルート証明書をインストールさせる強硬策に方針転換したのかな？
ちなみに各省庁、立法、司法の対応状況は、
首相官邸→GlobalSign Root CA
内閣官房→GlobalSign Root CA
内閣府→GlobalSign Root CA
復興庁→ApplicationCA2 Root
総務省→非対応（https指定すると404。ApplicationCA2 Rootを使用）
法務省→非対応（0秒でhttpにリダイレクト。ApplicationCA2 Rootを使用）
外務省→DigiCert Global Root CA
財務省→DigiCert Global Root CA
文科省→非対応（アクセス不能）
厚労省→DigiCert Global Root CA
農水省→非対応（akamai.netに付与された証明書が返ってくる）
経産省→非対応（akamai.netに付与された証明書が返ってくる）
国交省→ApplicationCA2 Root
環境省→GlobalSign Root CA
防衛省→非対応（アクセス不能）
会計検査院→非対応（https指定すると403、Baltimore CyberTrust Rootを使用している）
衆議院→非対応（アクセス不能）
参議院→非対応（アクセス不能）
最高裁判所→非対応（アクセス不能）
DigiCert Global Root CA使っている外務省、財務省、厚労省はhttpはリダイレクトされてhttpsになるけど他は両対応（非暗号化コンテンツの混在警告が出るところもあるので対応途上かもしれない）
https強制かつMozilla系はプリインストールされていない（恐らく今後もされない）ApplicationCA2 Rootはいまのところ官報ぐらいなのかな？
Re: (スコア:0)
「蹴っ飛ばした」って。申請してきたからMozillaの担当者が確認の電話してくれって返したら、日本側は電話しなかったどころかその後一切コメントを残してないんだから、「役人が途中で止めた」が正確な表現だろ。
Re: (スコア:0)
挙句の果てに、Baseline Requirementに抵触するコメントを発したのだから、日本国政府の担当者は大変な大失態。
このような運営者の証明書を信用する方がどうかしている。
参考:
・Bug 474706 - Add Japanese Government Application CA Root [mozilla.org]
・GPKIよ、おととい来やがれ！(タイトルで煽るスタイル) - yumetodoの旅とプログラミングとかの記録 [hateblo.jp]
Re: (スコア:0)
ただ各省庁の対応見ると、見たい人には見れないと困るとこほどApplicationCA2 Rootを使っている（使おうと画策している）ようにも見える
首相官邸や外務省の我が国の立場を広報する活動なんて、多くの人がアクセスできなければ困るのは国の方だが
オンライン申請や代替の効かない国のデータベースにアクセスするのにルート証明書が入ってなくて困るのはユーザー側だし
AppleとMicrosoftはApplicationCA2 Rootをプリインストールしてるようだし
ゴリ押し進めたら、プリインストールの要望が来てMozillaが折れるか、要望がうざいからMozillaからAppleやMicrosoftに日本政府がBaseline Requirementを遵守していないって通報が入って全部外されるかどっちかになる予感。
忘れてた (スコア:0)
ライブブックマークってなくなるんだっけ。今から拡張入れても変換されてしまったブックマークは復元不可能か…
Re: 忘れてた (スコア:1)
該当部分はFirefox feeds backup.opmlに吐き出されてます。
過去のbookmarkが欲しければ、プロファイル下のbookmarkbackupsフォルダに数世代残ってるはず。
Re: (スコア:0)
わたしも忘れてた。
入れる拡張ってどれがお勧め？
＃できれば今までのライブブックマークに動作が近いものがいいな
＃完全にオフトピ（苦笑）
Firefox 64て (スコア:0)
なんとなく3Dステックが実装されそうな名前ですね
# スリーディー、ではなく さんでぃー と読む
Re: (スコア:0)
主人公はレッサーパンダ？
Chromeもだけど (スコア:0)
メジャーとかマイナーの区別なく、バージョンアップで数字をひたすら加算していくのはイマイチわかりにくい感。
今はまだしも、3桁ぐらいになると「いまの最新はいくつだっけ」とかで悩みそうな。
暗号化とサーバ認証をセットで押し売りするシステム (スコア:0)
本来、通信の暗号化と、サーバ認証は別のはずなのに、
通信の暗号化を行うのにサーバ認証ガセットじゃないといけないっていう、
押し売りシステムが採用されてる
サーバ鍵・サーバ証明書とかなくても、DH鍵交換を使えばちゃんと暗号化が可能
次期SSL/TLSは、サーバ認証なしで通信の暗号化だけ行うってのも選択可能なシステムにすればいい
Re: (スコア:0)
ちょっと何言っているのか意味わかりません。
確かに暗号化と認証は別で、認証はするけど暗号化はしない、というのは用途によってアリだと思います。
一方で暗号化のみが有効なケースって何でしょう？
サーバ認証でなくクライアント認証でやるというなら、
結局、暗号化と認証はセットになるでしょうし。
Re: (スコア:0)
中間者攻撃を想定する必要がないが盗聴は想定する場合。
Re: (スコア:0)
SSL/TLSの規格上は、DH_anonが入っていて、匿名認証も可能です。
ただ、「誰かも保証されない相手」と暗号通信できたところで、守れるものはいったい何があるのでしょうか（つないだ相手が悪意の第三者、ということも考えられます）。実用問題としては、ブラウザでも通さないようになっています。
Re: (スコア:0)
暗号化も認証もしない平文HTTPより、暗号化だけするHTTPSのほうがましでしょう
またいまはフィッシング詐欺業者が当たり前のように証明書とる時代、サーバ証明の価値が大きく下がってる
サーバ証明書はフィッシング詐欺犯名義じゃなく、大手CDN事業者名義になってることが多く、本物と区別がつかない
Re: (スコア:0)
いまだこんな認識の人間がいるのか。
相手を認証しない暗号化はMITM攻撃にたいして全く無力です。
盗聴のリスクをまったく防止できません。
Re: (スコア:0)
ぐだぐだ言わずに実装するだけなのに何を抵抗してるのか
Re: (スコア:0)
MITM攻撃以外の盗聴を防止できることに価値を見出だしてしまう人がいるからでしょう。
Re: (スコア:0)
開発者がそういう理解しがたい理由で無認証暗号通信という選択肢を拒むんでしょうね
経路で盗聴されることを防ぐのと通信相手が本物であることの証明は独立したことなのに
Re: (スコア:0)
理解しがたいじゃなくて理解しろ。
何度でも繰り返すが、一般に暗号化だけでは経路で盗聴されることを防ぐことはできない。
セキュアでないものをセキュアだと思い込むのは立派なセキュリティリスクだし、
具体的なメリットもなくセキュリティリスクを増やすのは技術者倫理に反する。
反論するなら具体例を示してみろよ。
Re: (スコア:0)
盗聴が容易なアナログのコードレス電話を使うか、流通が制限されて相手が何者かがある程度保証されて、仮に送受信機が盗まれても執行処理ができる警察無線のようなシステムを選べ
傍受は困難だけど、通話相手が何者かの保証はされていない、成りすましで電話に出られる等本質的には盗聴を防げない
デジタルコードレス電話機みたいなのは要らないというようなもの
認証付き暗号しか認めない。気休めの暗号なんて要らない。いやなら平文通信しろって頑固すぎる
Re: (スコア:0)
そうですね、頑固過ぎました。
ここは雑談サイトなのだから、具体例に制限せず、的外れな喩え話も認めるべきでした。
失礼しました。
Re: (スコア:0)
Re: (スコア:0)
すでにRFC 8164 Opportunistic Security for HTTP/2 [ietf.org]というものがあって、しかもFirefoxはこれを実装しているんだ。
知ってはいたけどLiveBookmarkが機能が亡くなった (スコア:0)
RSSを手元で一覧で見るには最適の機能だったんだけど。
RSSリーダーサイトは色々あるが、見出しだけにできないし、マウスホバーで別のサイトに切り替えられないし、読む速度が段違いで遅くなる。
とりあえずLivemarks [mozilla.org]を入れてみたら、ローカルでは問題ない。
ところがFirefox Syncに対応していない。拡張機能の設定内容はSyncの対象外だった。
本体機能だった頃はFirefox Syncで同期していてくれたのに…機能が死ぬというのは悲しい。