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)
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で送信するし、以降はチャレンジレスポンスの
トークン付きなので経路が平文通信だろうが暗号破らない限り改竄不能だが。
ソース書いてやるよ (スコア: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のインターネットドラフトにも書いてある。
https://twitter.com/sakichan/status/1004931090178453504 [twitter.com]
> ACMEがホストやドメインの所有者からのリクエストとして確認する手段、
> HTTPとDNSとある（TLS-SNIのものは共有ホスティング環境での脆弱性により撤回。TLS-ALPNのものが提案されている）が、
> HTTPもTLSも最初の登録では本質的に第三者の攻撃は防ぎようがない。防げるならそもそも証明書要らないわけで。
https://twitter.com/sakichan/status/1004931769521467398 [twitter.com]
> 一方、DNSによる所有者確認はといえば、世の中のまだまだ普通の管理ではダメで、
> DNSSECでroot zoneから信頼のチェーンが確立している必要がある。
https://twitter.com/sakichan/status/1004932508981448704 [twitter.com]
> では世のDV証明書やOV証明書がそれらより安全か、というのは、一般論では何とも言えない。
https://twitter.com/sakichan/status/1004933590939942913 [twitter.com]
> という、煮えきらない話を @HiromitsuTakagi さんに裏でしたら、
> 初期登録時の MITM等のリスクは断熱した上での Let's Encrypt だという話でした。
「初期登録時の MITM等のリスク」は、セキュリティの専門家の高木浩光氏も認めている。