by
Anonymous Coward
on 2018年06月07日 16時05分
(#3421100)
EV SSL を使っていたようなところは別に移行していないだろうし、 DV SSL を Let's Encrypt に移したところで安全性は特に変わらないのでは。
OV はブラウザ上で DV と区別する手間が大きくて可哀想というか、 ぶっちゃけ一般人で違いを見分けられる人はほとんど居ない気がするので OV → DV にダウングレードして Let's Encrypt 化しているところがあったら まあ文句の一つも言いたくなるでしょうが、ユーザーが見分けられないなら 費用対効果が悪いので切る判断をしても仕方ないのでは。
上場企業や官公庁が使って何が悪いの？ (スコア:5, 興味深い)
EV SSL を使っていたようなところは別に移行していないだろうし、
DV SSL を Let's Encrypt に移したところで安全性は特に変わらないのでは。
OV はブラウザ上で DV と区別する手間が大きくて可哀想というか、
ぶっちゃけ一般人で違いを見分けられる人はほとんど居ない気がするので
OV → DV にダウングレードして Let's Encrypt 化しているところがあったら
まあ文句の一つも言いたくなるでしょうが、ユーザーが見分けられないなら
費用対効果が悪いので切る判断をしても仕方ないのでは。
Re:上場企業や官公庁が使って何が悪いの？ (スコア:1)
総務省が、公的機関の認証の信頼元を政府の中でできるようにするために、
政府の認証基盤を作ったのに、その下部組織であるスポーツ庁がgo.jpドメインで
政府の認証基盤を使っていないのはいかがなものかと
Re:上場企業や官公庁が使って何が悪いの？ (スコア:2, 興味深い)
https://it.srad.jp/story/18/03/01/072235/ [it.srad.jp]
そもそもその政府の認証基盤の信用度は (IdenTrust が信用した)Let's Encrypt よりも低いと Mozilla には判断されているわけで。
さっさと GPKI をたたんで、GPKI 使ってた所全部 Let's Encrypt にしたほうがましなんじゃないでしょうか。
(と言うまでもなく GPKI 使ってた所は セコムトラストの OV 証明書に移行 [gpki.go.jp] したり、DigiCert の OV 証明書に移行 [hellowork.go.jp] したりしてるみたいですけど。)
Re:上場企業や官公庁が使って何が悪いの？ (スコア:1)
信用度云々の前にMozillaの審査要件すら満たしていないという話では・・・・・単にGPKIの担当者がアホすぎたという問題。
その「担当者」がアホだろうが何だろうがGPKIの顔だった時代もあるので、今となってはGPKIが意地でもMozillaの軍門に下れるかって状態になってる。
その「Mozilla」は特に公的権力も持たないただの私的団体に過ぎないのに、証明書チェーンを流用してるプロダクトがあまりにも多くて事実上SSL世界の神になってるってのも問題といえば問題。
Re:上場企業や官公庁が使って何が悪いの？ (スコア:1)
現実問題、満たしてないと主張しているのはMozillaの中の人だけで、国際的な監査法人も認定を出しているし、MicrosoftやAppleなどは認めているんだけどね。
ただ、認めていないとしているのはMozillaだけ。
Mozillaとはそう言う組織なのだから、反発しても仕方が無い、大人になれ、と言う意味では担当者に非はあるかもしれない。
けど、政府側は日本国の法律に基づき、さらに公的機関が認定した監査を行うという手続きを取っているので、それ以上どうしようもないところはある。
特定の組織だけに特別な対応を実施するような事をしたら、統治機構の崩壊だからな。
ちなみにGPKIは最終的に大規模な政府電子化の為に考えられているものなので、ただのSSL証明書ではありません。
というか、証明書ってSSLだけだと思っているのかな。恥ずかしい奴だ
Re: (スコア:0)
AppleはMozilla準拠なので認めてないな。
事実上、端末ベースでルート証明書を認証する権力を握ってるのはMozillaかMicrosoftしかない状態。
あと監査法人はブラウザに対する支配力を持ってないので統制を証明することはできても権力はない。
で、Mozillaは公的機関でもなければ何らかの法律で拘束されるわけでもないただの団体。
「Mozillaルール」が絶対の正義なので、認めてもらいたい側は黙って従う必要がある。
Re: (スコア:0)
いや、認めてる。
iOSではずいぶん前から乗ってる [apple.com]。
ApplicationCA2 Root ってのがそれ。
いや、Mozillaも法律によって制限を受けるよ。当然ながら自分のところのルール如何に関わらず、必ず法律が優先する。少なくとも現地法がある。
この構造は行政側も当然なので、一部だけ特別扱いして対応しなければ駄目だ、と言うルールを振りかざされても行政は当然対
Re: (スコア:0)
GPKIをMozillaが信頼しない件のタレコミで粘着されていたアンチMozillaの方でしょうか。
それとも、"Bug 870185 - Add Renewed Japanese Government Application CA Root certificate [mozilla.org]" で墓穴をほってしまった担当者か、GPKI関係者でしょうか。
日本政府に忖度して信頼済み証明書にGPKIを加えてしまうようなMicrosoftこそ、信用出来ないです。
Re: (スコア:0)
アンチとかなんとかレッテルを貼らないと正しさを証明できないなら発言を慎んだ方がいいと思うよ
Re: (スコア:0)
客観的に見てみ。
団体の名前とか全部象徴化して普通に考えてみ？
・先進七カ国に数えられる国の政府が法律・政令に基づき管理しており、法的拘束力がある
・国際的な基準に従っている事を、世界三大監査法人の一つが証明している
・現在世界でシェアを三分にする環境のうち、2つでは既に使用ができる
・法律的裏付けもない任意団体の一職員の判断により、最後のこされた主要環境においては、ユーザーに危険な状況を強いている
どうして客観視ができないんだろうか。
自分たちの世界が全てだと思ってしまうと、ああいう反応になるのだと思う。
Re: (スコア:0)
別ACだけど
ほっとけば失効するから、失効管理しないって言っちゃうような
PKIを信じる方がリスクは大きいと思いますけどね・・・
DigiNotarでひどいことになったのに
よく、MSもAppleもリストに入れたよね。
あれはオランダ政府系でしたっけ？
Re: (スコア:0)
Appleが認めているというソース出して
Re: (スコア:0)
iOS 11 で利用できる信頼されたルート証明書の一覧 https://support.apple.com/ja-jp/HT208125 [apple.com]
ここに「ApplicationCA2 Root 」ってのがあるじゃろ。
FingerPrint:12 6B F0 1C 10 94 D2 F0 CA 2E 35 23 80 B3 C7 24 29 45 46 CC C6 55 97 BE F7 F1 2D 8A 17 1F 19 84
の奴。
Re: (スコア:0)
いや、そんなのは(Mozilla関係なくいずれかの組織が信頼しないのは)、
GPKIを立ち上げる時にわかっていたわけだし、
信頼を得るためなら(もっと言うと国民の利便性を考えるなら)、
どこかの認証局(それこそIdenTrustとか)に信頼された認証局としてスタートして
ルート認証局を目指すというやり方もあったわけでしょう？
そうしなかったという事は、利便性(信頼できる認証か判断しずらい)なんて知ったこっちゃないわけだから
「Mozillaが信用していない」はLet's Encryptを使う理由にはならないかと、
ドメインを「go.jp」として、認証局をGPKIにしないというのは
「政府関係の発表の体裁はとるけど、本当に政府関係の発表かは保証しないよ(GPKIでないし)」
と言っていることになりませんかね？
Re:上場企業や官公庁が使って何が悪いの？ (スコア:1)
OVは見分けるのも大変だけど、認証プロセスが規格化されてないので信用できるかどうかも怪しい。
DVよりはマシかもしれないってレベルなのでお金を払う価値があるかと言えばない。
その点、EVは確実なんだけどね。認証局がデタラメな発行をしたらブラウザに認証局ごと無効化されるので。
あと、官公庁はSSL証明書なんか比較にならないレベルでgo.jpドメインが信用できるので Let's Encrypt で十分。
企業もco.jpだったらwhois情報を信用してもほぼ大丈夫なので、やはり Let's Encrypt で問題ない。
Re: (スコア:0)
ドメイン名自体の信頼度ではそのとおりですが、
DNSや途中の経路が攻撃されていて偽物の.go.jpにアクセスしているかどうかはどうやって判別するんでしょうか。
Re:上場企業や官公庁が使って何が悪いの？ (スコア:1)
偽物のgo.jpのSSL証明書を取得しようと思ったらACMEを破って発行させなきゃいけないので現実的に無理。
仮に可能なことが発覚したらACMEのセキュリティホールってことで対処されてしまうよ。
Re: (スコア:0)
> 仮に可能なことが発覚したらACMEのセキュリティホールってことで対処されてしまうよ。
もう可能なことは発覚してますけど
ACMEだと http://example.go.jp/.well-known/acme-challenge/ [example.go.jp] 内に指定されたトークンを配置することで example.go.jp 所有者と認定するの
だから、ACMEの認証サーバと example.go.jp 間のhttp平文通信を改竄できる人ならば、トークンを配置したかのように見せかける攻撃が理論上可能なことは自明
tls証明書の発行プロセスで安全なhttps接続を要求するわけにはいかないので、これは仕様上避けられないからやむを得ず存在する脆弱性なので、
「ACMEのセキュリティホールってことで対処」することはできない
Re: (スコア:0)
可能だと発覚してるならその文献を提示してくれ。
クライアント->サーバへのCSR要求やチャレンジはSSLで送信するし、以降はチャレンジレスポンスの
トークン付きなので経路が平文通信だろうが暗号破らない限り改竄不能だが。
Re:上場企業や官公庁が使って何が悪いの？ (スコア:1)
> クライアント->サーバへのCSR要求やチャレンジはSSLで送信するし、以降はチャレンジレスポンスの
> トークン付きなので経路が平文通信だろうが暗号破らない限り改竄不能だが。
「トークン付きなので経路が平文通信だろうが暗号破らない限り改竄不能」なのは正しいけど、
なりすましの意味を完全に勘違いしている。
その「ACMEクライアント」を実行するのが、不正に証明書を発行したい悪意のある人物なの。
クライアント->サーバへのCSR要求を悪意のある人物が行った結果、悪意のある人物がチャレンジレスポンスのトークンを入手できる。
ここまではACMEの普通の仕様なので明らかだろう。
で、その次にACMEサーバから http://example.go.jp/.well-known/acme-challenge/ [example.go.jp] への通信（ここは平文のhttp）を改竄し、
そのチャレンジレスポンスのトークンを返す（これは安全な通信ではないので通信を改竄できれば可能）。
すると、悪意のある人物が実行した「ACMEクライアント」に対して、正規の証明書が発行される。
（ACMEクライアントとACMEサーバの間の通信は、TLSで暗号化されているが、その「ACMEクライアント」を実行しているのが悪意のある人物というわけ）
ソース書いてやるよ (スコア:0)
ACMEが危険なのは仕組みを理解していれば自明だし、そもそもACME開発者も認めているんだけど、
ソース出せとのことなので日本語のソースを出す。
OV証明書とEV証明書の仕事をしていている崎山伸夫氏のツイートより引用
https://twitter.com/sakichan/status/1004929519726104576 [twitter.com]
https://twitter.com/sakichan/status/1004930142718705664 [twitter.com]
> Let's Encryptの基盤となるACMEという証明書自動管理のプロトコル、非常に巧妙ではあるけれども、
> 少なくとも最初の証明書取得時の第三者からの攻撃からは完全に自由とは言えない。
> それは、ACMEのインターネットドラフトにも書いてある。
Re: (スコア:0)
SSL証明書の被提供側のページビューが増えたときに、
Let's Encrypt など提供者側の負荷が大きくなって
被提供側のページ表示の足を引っ張るということはないの？
Re: (スコア:0)
え？
SSL/TLSのサイトにアクセスするごとに、認証局にもアクセスされてるの？
Re:上場企業や官公庁が使って何が悪いの？ (スコア:1)
今時のブラウザならハンドシェイクごとには証明書失効確認のためにする
しなかったらrevokeした証明書が有効のままになる
けど、その認証局のサーバ負荷なんて今時無視できるぐらい少ない
困るのはDDosやDosのような異常アクセスだけ
Re: (スコア:0)
発行元が信頼できるかなどでルート証明機関の確認などの通信が発生しますよ。
自己署名証明書を使っていると気づかないと思いますが。
Re:上場企業や官公庁が使って何が悪いの？ (スコア:1)
発行元が信頼てきるかの確認の通信はありませんよ
revokeされてないかの確認の通信だけです
ブラウザの設定で証明書の取り消し確認を無効にすればこの通信は発生しません
Re:上場企業や官公庁が使って何が悪いの？ (スコア:1)
CRL (Certificate Revocation List)や、OCSP (Online Certificate Status Protocol)ですね。
CRL は、配布ポイントを複数指定できる上に、発行間隔より頻繁にアクセスして意味のあるようなもんでもないので、それほどの負荷にはならないのでは。
Re: (スコア:0)
ルート証明機関の確認ってなんですかぁ？
Re: (スコア:0)
少し前のWindowsから、ウェブサイトへの初回アクセス時に、対応するルート証明書をダウンロードしてくる仕組みがあるそうです。もしかしたら、それのこともしれません。
Re: (スコア:0)
無効になった証明書リストに入ってないかとか、本当はきちんと通信して確認しなきゃいけないんじゃないか。
Re: (スコア:0)
サーバーが本物だろうが通信経路が安全だろうがどうせ他から情報は漏れるので無駄
Re: (スコア:0)
OVは証明書屋が少しでも高い証明書を売りつけたくて業界あげて騙しにかかっているが実際DVに対する優位はなにもないと言っていい