上場企業やgo.jpドメインでもLet's Encryptのサーバ証明書の利用が広がる 62
ストーリー by hylom
スラドですらちゃんと買っているのに 部門より
スラドですらちゃんと買っているのに 部門より
無償でSSL/TLS証明書を提供するサービス「Let's Encrypt」の利用が広まっているが、このサービスで発行された証明書を利用する上場企業や官公庁が登場したことが一部で話題になっている（上原哲太郎氏のTweet、Shigeki Ohtsu氏のTweet）。
SSL/TLS証明書の役割の1つは暗号化通信に利用するための鍵を提供することだが、別の役割としてその接続先を保証するというものもある。Let's Encryptは接続先サーバーがそのドメイン名に適切に紐づけられていることについては保証するが、証明書の所有者については保証しない。そのため、企業などでの利用には適さないとされている。
（以下、追記と訂正＠6/8 0:55）セキュリティ研究家の高木浩光氏によると、「TLS（SSL）における証明書の役割は中間者攻撃を防ぐことであり、それを上回りもしないし下回りもしない。（実在証明の機能はTLS（SSL）の機能ではない。）」とのこと（指摘Tweet）。
SSL/TLS証明書にはドメインの認証のみを行うDV証明書と運営者の実在性審査を行うOV証明書、厳格に運営者の審査を行うEV証明書があるが（解説記事）、高木氏によると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)
GPKIをMozillaが信頼しない件のタレコミで粘着されていたアンチMozillaの方でしょうか。
それとも、"Bug 870185 - Add Renewed Japanese Government Application CA Root certificate [mozilla.org]" で墓穴をほってしまった担当者か、GPKI関係者でしょうか。
日本政府に忖度して信頼済み証明書にGPKIを加えてしまうようなMicrosoftこそ、信用出来ないです。
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:上場企業や官公庁が使って何が悪いの？ (スコア:1)
> クライアント->サーバへのCSR要求やチャレンジはSSLで送信するし、以降はチャレンジレスポンスの
> トークン付きなので経路が平文通信だろうが暗号破らない限り改竄不能だが。
「トークン付きなので経路が平文通信だろうが暗号破らない限り改竄不能」なのは正しいけど、
なりすましの意味を完全に勘違いしている。
その「ACMEクライアント」を実行するのが、不正に証明書を発行したい悪意のある人物なの。
クライアント->サーバへのCSR要求を悪意のある人物が行った結果、悪意のある人物がチャレンジレスポンスのトークンを入手できる。
ここまではACMEの普通の仕様なので明らかだろう。
で、その次にACMEサーバから http://example.go.jp/.well-known/acme-challenge/ [example.go.jp] への通信（ここは平文のhttp）を改竄し、
そのチャレンジレスポンスのトークンを返す（これは安全な通信ではないので通信を改竄できれば可能）。
すると、悪意のある人物が実行した「ACMEクライアント」に対して、正規の証明書が発行される。
（ACMEクライアントとACMEサーバの間の通信は、TLSで暗号化されているが、その「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)
無効になった証明書リストに入ってないかとか、本当はきちんと通信して確認しなきゃいけないんじゃないか。
Re: (スコア:0)
サーバーが本物だろうが通信経路が安全だろうがどうせ他から情報は漏れるので無駄
指摘点がちょっと違うような (スコア:1)
暗号化のためのTLS : 基本は歓迎、LEで不都合はない
サーバ認証のためのTLS : DV SSL(TLS)だと相手の存在が保障できない(のでLEだと...)
となるが
EV SSLなところ : 問題なし
上場企業でLE :
いままでEV SSL : それはさすがに... ★
いままでOV SSL : 見分けはつかないな...
政府系でLE : 本来はEVだとうれしいけど、go.jpだったら(一応)なりすましとかは問題ない(サブレベル単位で保障ともいえる)、なのでDVでも問題はあんまない
ような気がするので★以外はいいんじゃないかなあ...
DV証明書はドメイン所有者になりすまして証明書を取得する攻撃を防げない (スコア:0)
DV証明書はドメイン所有者の確認を平文通信のhttpやdnsやwhoisメールアドレスでやるので
通信が改ざんされて場合、悪意のある人物がドメイン所有者になりすまして証明書を取得できるので危険
電話、Fax、郵送などのインターネット以外の経路を併用して認証するOVやEVの方が安全性が高い
スラドはDVなのでLet'sと同レベル
お金があるならEV証明書にしよう (スコア:1)
一般ユーザ↔webサーバ間のインターネット通信同様、webサーバ↔認証局サーバ間のインターネット通信も改ざんされ得るのでDV証明書は証明書発行プロセス自体が安全ではない
srad.jp とLet's Encrypt認証局の経路に関わる人（ispの中の人）やdnsに毒入れできる人なら本物ののsrad.jpの証明書を取得できてしまう
ログは残るから後からrevokeはできるけど金銭を扱うサイトなどで被害が出てからでは後の祭り
DV証明書は妥協の産物に過ぎないので、お金があるならEV証明書にしよう
googleやamazonがEVにしないのは、EVだとドメイン名を表示しないSafariのような糞ブラウザに責任がある
ドメインも確認しないと同名の会社を設立する攻撃に弱くなるからね
まぁgoogleやamazonはドメイン名自体がブランドだからいずれにしてもEVは使いたくないかもしれないけど
Re:お金があるならEV証明書にしよう (スコア:1)
それをいったらEVも証明書発行プロセスに関わる人もできちゃうじゃんね。
それって、どんなセキュリティもrootのパスワードが脆弱なら意味が無いし
物理的にサーバにアクセスできるなら何もかも無駄、みたいな議論じゃねえの。
EV証明書の本質はそこじゃ無いと思うけど。
Re: (スコア:0)
> それをいったらEVも証明書発行プロセスに関わる人もできちゃうじゃんね。
それはそうだけど、発行プロセスに関わる人でなくても、「物理的にサーバにアクセス」できなくても、
通信経路のデータを改竄できる人（通信を中継する電気通信事業者・ISPを含む）ならば不正な証明書発行ができてしまうので問題
そして、通信経路のデータ改竄が有り得ないならば、そもそも https の必要性が大幅に減るという皮肉な状況になっている
ACMEだと http://example.com/.well-known/acme-challenge/ [example.com] 内に指定されたトークンを配置することで example.com 所有者と認定するの
だから
Re: (スコア:0)
うちの会社でも最近Let's Encryptを使い始めました。
管理者になぜLet's Encryptにしたのか聞いたところhttps化の売り込み営業が
うるさいからとの事。だから暗号化とか実在性とかはあまり考えてないみたい。
検索順位は気にしてたみたいけど。
まあ組織が違えば目的も違うって事で。
Re: (スコア:0)
別にDVならどの認証局でも変わらんよ
ぼったくり価格でDVを買うのは情弱だよ
comodoのdv使って「スラドですらちゃんと買っているのに 部門より」と言ってるhylomは、ただの情弱の馬鹿
価格じゃなくて認証レベル（DV, OV, EV）で判断しよう
Re: (スコア:0)
勤めている会社はどうかなと見たら、平文だった。
まあ、困るような会社ではないのは確かだが。
そういえば今度、プライバシーマーク取るらしいが、WebページがHTTPSであること、って要件はないんだろうか。
まあ、Webページが改ざんされても、個人情報が洩れるわけではないが、問い合わせ先が改ざんされたら、まずい気がする。
Re: (スコア:0)
信頼できない証明書の警告を無視しろという案内がまかり通ってる世の中だと、
アクセス数（ユニークユーザ数）の少ないところは、なりすまされても閲覧者がしばらく気づかず発覚しなかったりして。
Re: (スコア:0)
最低限問い合わせページがHTTPSであることは要求されますよ。
＃でもサイト全体がHTTPSでなくても許される。良いのか。
Re: (スコア:0)
問い合わせページに代表電話番号が記載されているだけの可能性
問い合わせページに代表FAX番号が記載されているだけの可能性
問い合わせページに代表メールアドレスが記載されているだけの可能性
HTTPSが要求されるのは、フォームが用意されている場合だけですね。
Re: (スコア:0)
LE の dns-01 は TXT レコードにそのセッション限り有効のワンタイムトークンを登録する。
別に whois のメールアドレスは要らない。
なのでコンテンツサーバの管理権限がないと不正な証明書取得は難しい。
ここら辺、ワイルドカード証明書を自動取得・更新するスクリプト書いていて、
よくできてるなと思った。
DNS の通信の安全性ってことなら、LE が使用するキャッシュサーバの問題になるでしょ。
コンテンツサーバ乗っ取られてたらもう論外だし、
コンテンツサーバと LE キャッシュサーバの間の MITM とか考え出したらきりがない。
そういう視点では、LE は取得の仕方にも依るけどヘタな DV 証明書より信頼性あるよ。
Re: (スコア:0)
この数年の動向を見ると証明書発行機関の信頼性もあるかな．
怪しい発行機関がわんさかあったわけで，企業に金払っていれば安心・長期保証というわけではない．
政府認証基盤よりも，Let's Encrypt のほうが，（ガイドライン上は）国際的に認められているという現実もある．
Re: (スコア:0)
以前、地方自治体のWebサイトに "NEC Corporation"という名前で
EV証明書が発行されていた事もあるので、EVだからと手放しで安全とは言い切れない。
無理にEV証明書にしなくとも、
商品名.jp みたいなドメインを乱立しないで、
サブドメインを活用したDV証明書を使ってくれた方がありがたい。
Re: (スコア:0)
EVで証明できるのはなりすましではないことだけ
なりすましが他に存在することは全く防げない
嘘乙 (スコア:0)
> Let's Encryptは接続先サーバーがそのドメイン名に適切に紐づけられていることについては保証するが、証明書の所有者については保証しない。そのため、企業などでの利用には適さないとされている。
何を根拠にそんなこと言ってるの？
Re:嘘乙 (スコア:1)
> 「証明書の所有者については保証しない」
「証明書の保有者が特定名称の企業、団体の名前であることは保証する」
くらいがせいぜいのところ。それ以上は何も保証してくれない。同名の別企業でも証明書は発行される。
「（もっと高価なOV, EV証明書を買ってくれないと）企業などでの利用に適さないと主張しているSSL販売業者が存在する」
というくらいが正確。
Re: (スコア:0)
OV, EV証明書を買っておけばLet's Encryptを使っても問題ないということか
一方、三菱UFJ銀行では… (スコア:0)
三菱UFJ銀行も証明書ネタで盛り上がっていますね。
EV SSLの表示名が気になるなら、4月1日付でやればよかったのに。
〔三菱ＵＦＪダイレクト〕銀行名変更にともなうサーバ証明書の切替について | 三菱ＵＦＪ銀行 [bk.mufg.jp]
Re:「スラドですらちゃんと買っているのに」 (スコア:1)
https://license.osdn.jp/ [license.osdn.jp]で使ってるみたいですよ。。。
#https://www.licenseonline.jp/はCyberTrust
Re: (スコア:0)
あのCOMODOだけどね
https://www.google.co.jp/search?q=Comodo%E4%BA%8B%E4%BB%B6 [google.co.jp]
Re:「スラドですらちゃんと買っているのに」 (スコア:1)
スラドなんかhttpで十分じゃん。
スラドとの通信が改竄されて困る奴なんかいるの?
Re:「スラドですらちゃんと買っているのに」 (スコア:1)
例えば記事に誤字やtypoがあったとき、
誰の責任かわらから無くなるじゃん
Re:「スラドですらちゃんと買っているのに」 (スコア:2, すばらしい洞察)
今ですら誰も責任取ってないんだから何も変わらないでしょ。
Re: (スコア:0)
ヘッドレスさんは少なくとも直しますよ
コメントで報告もしますよ
Re: (スコア:0)
「わらから無くなる」の責任をAnonymous Cowardが取ってくれるのか？
Re:「スラドですらちゃんと買っているのに」 (スコア:1, おもしろおかしい)
hylomの記事である保証があることで、気をつけて読むことができる。
hylomが書いたことが確かではないのに記事を読んでしまうのは危険。
Re: (スコア:0)
そもそもSSL証明書の取得時はDV証明書の場合でも少なくとも電話での運営者確認があるものだと勘違いしていたのが間違いの発端です
https://twitter.com/hylom/status/1004754909957242880 [twitter.com]
domain-validated とは
Re:「スラドですらちゃんと買っているのに」 (スコア:1)
私のメインバンクは旧シマンテックなので安心です。
〔三菱ＵＦＪダイレクト〕銀行名変更にともなうサーバ証明書の切替について
http://direct.bk.mufg.jp/info_news/20180522_server/index.html [bk.mufg.jp]