サーバー証明書を無料発行する「Let's Encrypt」がパブリックベータに移行 66
ストーリー by headless
発行 部門より
発行 部門より
Printable is bad. 曰く、
Internet Security Research Group(ISRG)は3日、無料でSSL/TLSサーバー証明書を発行する「Let's Encrypt」のパブリックベータ移行を発表した。今後は招待されるのを待つことなく、ドメイン名の所有者は誰でも無料で証明書を取得できるようになる(公式ブログでのアナウンス、 和訳)。
Let's EncryptはWeb全体をHTTPS(TLS)化し、安全性を高めることを目的として証明書を無料で発行している。発行される証明書は米大手認証局(CA) IdenTrust社のルート証明書とクロスルートしているため、すべての主要ブラウザが標準で対応している。
具体的な証明書の取得方法については「Let's Encrypt の使い方」が参考になる。細かなコマンドラインオプションなどを知りたい場合には「Let's Encrypt client documentation」を読むことをおすすめしたい。
実際に試してみたところ、CSR(署名リクエスト)の生成といった手動が自動化されており、クライアントのインストールも含めて数分程度の作業で証明書の取得が完了した。
IISの場合のやり方 (スコア:1)
http://blog.shibayan.jp/entry/20151111/1447172124 [shibayan.jp]
クローズドベータ時代のものだから今はまた変更点があるかもしれないが。
IISに限らず、非対応環境で証明書の取得のみを行いたい場合に参考になるだろう。
Re: (スコア:0)
うへえ。有効期間90日で頻繁な更新が必要なのに、取得方法がLinuxべったりで他環境を考慮していないのか。
「非対応環境で証明書の取得のみを行いたい場合」もなにも、要するに「そのためだけにLinux使え」ってだけだよね。
こりゃWindows環境で使うのはつらいな。
Re: (スコア:0)
自動化ツールのwindow版は時が解決してくれそうな気がするけど（まだベータ版ですし）、サーバーを一から管理してないレンタルサーバー勢なんかには90日はハードル高いよねぇ
Re: (スコア:0)
ぱらっと一部だけみただけですが、「Let's Encrypt client documentation」に、dockerやFreeBSDがどうこうとありました。
Windows関連はみていないのですが、確認してみては。
Re: (スコア:0)
主眼はプロトコルの標準化を提案することにあって、公式クライアントといえどもサンプル実装にすぎないので(すでにnode-letsencryptも開発中)。
「自分で作れ」ないしは「誰かが作ってくれるのを待て」ってこった。
マヌケな俺への十戒 (スコア:1)
漠然と「httpsは暗号化されてて安全」とだけ考えてる俺は、何に気をつけるべきなんだろ？
この証明書が発行されてても、「せっかく色々と金をかけたドメインだから未来永劫信頼して欲しいし、そのために全方位紳士的に振舞いたい」と願う管理人が運営しているとは限らない、とか？（mega.nzが紳士的かと言えばアレだけどｗ）
通信傍受されまくったりする可能性あんの？
あと何だ？10個挙げるまで帰れま10。
Let's Encrypt （に限らず格安系認証局）のドメイン所有者の認証プロセスは脆弱 (スコア:5, 興味深い)
「httpsは暗号化されてて安全」 から 「EV証明書（アドレスバーが緑色になるなどする証明書）は実在証明されているので、なりすましや通信傍受・改竄に対して安全」 に考えを改めれば良いと思います。
Let's Encrypt の悪意のあるサイトへの証明書発行ポリシーについては フィッシング詐欺やマルウェアとの戦いにおける認証局の役割 [letsencrypt.jp] に書かれています。
ということで、DV証明書については、「httpsは暗号化されてて安全」というより「httpsで通信が暗号化されている」とだけ解釈すれば良いと思います。暗号化されていたとしても、通信相手は詐欺師かもしれません。ドメイン名を認証している証明書なのですから、そのドメイン名を既に信頼していない限り、安全面では意味がありません。
技術的には、Let's Encrypt に限らず、RapidSSL などの格安系認証局のDV証明書に関しては、証明書発行プロセスにおけるドメイン所有者の認証プロセスに脆弱性があるので、通信の暗号化という点においても、絶対に安全とはいえません。PGP も、暗号化に使おうとしている相手の公開鍵が、本当にその通信相手のものなのかをインターネット経由で安全に確認できないという、同じジレンマを抱えています（そのため、完全に安全にしたいのならば、リアルで会ってフィンガープリントを渡すといった手法を取る必要があります）。
例えば、Let's Encrypt ではドメイン所有者であることの認証を行う際に、証明書を発行するドメイン名に対するAレコードをDNSでチェックして、当該IPアドレスと通信を行うことで、ドメイン所有者であることを認証しています。
DNSサーバとの通信は安全ではない（平文での通信なので改ざんに弱い）ので、Let's Encrypt のサーバとDNSサーバ（Let's Encrypt と直接通信しているDNSサーバとの通信が安全な方法であったとしても、その先が安全でないと意味がない）との間の通信が改ざんされた場合やDNSに毒入れがなされた場合には、悪意のある第三者が実行した Let's Encrypt クライアントで正常に認証されてしまい、悪意のある第三者が正規のDV証明書を入手してしまう可能性があります。
最も、実際にその証明書を悪用するためには、一般のユーザーとWebサーバ（もしくはDNSサーバ）間という別の経路の通信も改ざんする必要があるので、悪用は極めて難しくなるかと思います（例えば、ユーザーが悪意のあるWi-Fiアクセスポイントを使ったことによる通信の改ざんの場合、認証局とDNSサーバの間の通信は改ざんできないので、そういった攻撃手段は防げます）。
このように、インターネット経由だけでドメイン所有者を安全に認証することは不可能なので、昔はEV証明書でなくても、サーバ証明書取得者の確認を、電話や書留郵便などのインターネット以外の経路でやるのが一般的だったのですが、価格競争に陥ってDV証明書ではインターネット経由の簡易的な認証が一般的になりました。
なお、インターネット経由での簡易的なドメイン所有者の認証方法としては、webmaster@example.com でのメール（平文）が受け取れば認証OKとか、Webページのルート（HTTPでOK）に指定のMETAタグを書けば認証OKといった方法がとられています。
ただし、これが悪い事かというと、個人的にはそうは思いません。オレオレ証明書のように、ユーザーとサーバ間の通信が改ざんされた場合に悪用できてしまう証明書とは違って、二経路の通信が改ざんされない限り悪用できなくなるので、安全性は格段に増します。
更に高い安全性が必要な用途では、EV証明書を使えば良いと思います。Let's Encrypt の運営チームも、高い安全性が要求されるケースではDV証明書の使用は勧めていません。
# Let's Encrypt が普及してその理念通りに全てのWebサイトがhttps化すると、企業はより消費者が安心する EV証明書に移行していくでしょうから、高価なEV証明書の売り上げが伸びて認証局がより儲かる結果となるでしょう。
Re: (スコア:0)
証明書でのhttps接続が当たり前になるのであれば、
ブラウザでEV証明書以外は「安全だよ」的な表示を行うのを止めて貰いたいと思うけど。
なってたかな？
Re: (スコア:0)
かなり先の話だが、Chromeが検討しているようだ
http://security.srad.jp/story/14/12/18/052212/ [security.srad.jp]
Re: (スコア:0)
EVがDVより信頼性が高く見た目も変えられていることから、認証局も格付けして、それを表示に反映するといいのかも。
10 EV
8 信頼性の高い認証局の署名付き
5 信頼性が少し落ちるけど有名どころの有料の署名付き
3 Lets encryptのような無料の署名付き
1 オレオレ
0 http
有料だから信頼出来るってわけじゃないし、有料でも3同等としてもいいところもあるだろう。
# Paypal,Twitter,AppleなどはSymantecのEV。AmazonやFacebookやMicrosoftやYahooなどのIT巨人でもEVじゃない。
# Googleは自分で自分を署名してるのはどうなんだろう
Re:Let's Encrypt （に限らず格安系認証局）のドメイン所有者の認証プロセスは脆弱 (スコア:1)
技術的にEV以外の証明書に格付けしても意味はない(CPSを機械的に検証できないから)。というかまさにその問題を解消するためにEVが開発されたのだから、話が反対。EV以外の証明書の格付けは証明書業者がEVの値段を少しでも釣り上げるためにやっていると言っても過言ではない。
Re: (スコア:0, 荒らし)
またこいつ長文かよ。
少なくとも読みやすいようにまとめてほしい。
Re:Let's Encrypt （に限らず格安系認証局）のドメイン所有者の認証プロセスは脆弱 (スコア:1)
制限字数140文字以内のtwitterにおいても120文字程度でtweetを
繰り返しているとからかわれたこと何度かあります。
そのサービス提供場所次第でいろいろな流派が
ひしめいているのだと実感しています。
Re:マヌケな俺への十戒 (スコア:4, すばらしい洞察)
今まで通り、通信相手が正しいかどうかを見ればいいんじゃない? 本物のサイトでも偽サイトでも正しく暗号化はできるので、じゃあどっちが本物かというところを見ればいい。
そしてそれは今までも必要だったことだから、何も変わらない。
Re:マヌケな俺への十戒 (スコア:1)
それは対案の組みようがない無意味な批判だよね。httpsだから安全といえるのは接続先がユーザの真に意図したサイトであることが確認できていて、かつ暗号化もされているときだから。
仮に今までSSL証明書を持ってるかどうかで人格を判断できると思ってたようだったら、成年後見人制度も検討してみていいんじゃない?
Re:マヌケな俺への十戒 (スコア:1)
tls 1.2を含め、NSAは傍受できてるという憶測もある。
十中八九Torを使わん限り安全ではない。
Re:マヌケな俺への十戒 (スコア:1)
Tor上の「通信経路」は暗号化されていますが、exit nodeからは「通信内容」は丸見えなのです。
まあ、TLS 1.2を解読できる…楕円曲線上の離散対数問題を多項式時間で解読できるような量子コンピュータを秘密裏に実用化していた場合、
我々は無力です。バーナム(なおかつワンタイムパッド)暗号でも使ってください。
(キーサインパーティーで乱数を書き込んだ3TBのHDDを手渡すという鍵配送はそれなりにアレゲかもしれない)
匿名化ツール『Tor』の落とし穴（1） 『 大使館等の通信傍受に成功 』 WIRED.jp [wired.jp]
匿名化ツール「Tor」で大使館などのパスワード100件を入手 - ITmedia ニュース [itmedia.co.jp]
Re: (スコア:0)
> 楕円曲線上の離散対数問題を多項式時間で解読できるような量子コンピュータを秘密裏に実用化していた場合
通信手順や実装などの方に脆弱性があってそれを押さえてる、とかはわりと有り得る話だと思う。
あと、「多項式時間で解ける」と「実用的な量子コンピューティングで解ける」は別の話。
# 量子コンピュータ等の特殊な演算方式は実用的な多項式時間で解けない問題を解くために有力視されている技術
脆弱性などの攻撃も含めて、なにか一つでも突破されていたら安全は保証できなくなります。
Re:マヌケな俺への十戒 (スコア:1)
厳密に言えば「汎用ゲートモデル量子コンピュータ」ですね。
1994年 「ショアのアルゴリズム」は、古典コンピュータでは準指数時間でしか解けなかった素因数分解問題を、多項式時間で解けることを示したのですよね。
1995年 Boneh-Liptonの論文 [stanford.edu]により「ショアのアルゴリズム」は一般の群の離散対数問題にも容易に適用できる、すなわち楕円曲線上の離散対数問題も量子アルゴリズムなら多項式時間で解けることがわかりました。
2013年 エドワード・スノーデンの開示文書によると、NSAにおいて暗号解読のための実用化が研究されているそうです。
1946年2月14日 一般にも報道されたENIAC以前にも電子計算機はありました、Colossusは1943年12月に完成していましたが、1970年代までその存在は秘密にされていたそうです。
# 2015年9月 Symantecはgoogle.comのEV証明書を不正に発行しました。
# もしもNSAの工作員が「政府から正規に発行された偽物の身分証」でGoogleやAmazonの従業員として従事していた場合、
#「正規の鍵で署名された正当性のある偽物の証明書」というのも実現できるかもしれませんね。
Re: (スコア:0)
httpsは、せいぜいチェックサムを重ねがけしてるモードから、相手局を精一杯認証してるモードまでピンキリあること
それと、いくらhttpsで守っても、だまされたらそんだけ
Re: (スコア:0)
証明書の種類に気をつければいいんじゃないでしょうか。
EV証明書とそれ以外という区別で問題ありません。
Re: (スコア:0)
OV証明書は、はっきり言って証明書売っている業者がEV証明書にさらに一段高い値付けをできるようにするという意味しかないね。
むしろ誰でも証明書がとれるのは脆弱性では (スコア:1)
悪いこと考えてる人間もノーリスクで利用できる仕組みにしたらhttpsでもやばいという状況を量産するだけなのでは……。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:むしろ誰でも証明書がとれるのは脆弱性では (スコア:1)
> 悪いこと考えてる人間もノーリスクで利用できる
OSS全否定とは大きく出たな
Re:むしろ誰でも証明書がとれるのは脆弱性では (スコア:1)
「もともとそうだったのがやりやすくなるだけ」って考え方もできる。
むしろ、そういう認識が広まればEV証明書の意義がより明確に活用されるし、
カジュアルなユーザもTLSを使いやすくなって全体的なセキュリティが向上する。
Re: (スコア:0)
httpsである事自体は元々何も保証してないって状況のままでは
認証局としての信頼性は？ (スコア:0)
半年後にクラックされて閉鎖しそうな予感…
Re: (スコア:0)
IdenTrustとやらを信頼済みルート認証局からはずしとこうかなあ…。
Re:認証局としての信頼性は？ (スコア:2)
認証局は、WebTrust for CA に合格していることで内部統制等に対する信頼性を担保しています。(これに合格することは、ブラウザの「信頼されたルート証明書」として登録されるための条件です。日本政府のGPKIルート証明書も同様の手順を踏んで、登録されました。)
IdenTrustを信頼されたルート証明書から外すのは個人の自由ですが、外すのはそれだけで良いのですか? 他にも同程度にしか信頼できない (WebTrustに合格した程度の) 認証局はたくさんありませんか?
HIRATA Yasuyuki
Re: (スコア:0)
ブラウザのルート証明書プログラムにも申請済みで、クロスルートは普通にブラウザで認識できるようになるまでのつなぎだよ(一般にクロスルートというのはそういうものだ。なんか2048-bitの証明書を使うとき必要なものだとか思ってる人がいそうだけど)。
Re: (スコア:0)
やってることは、DynamicDNS のサービスと似たようなもんですよ。
Let's Encryptのサーバから、その名前でアクセスできることが確認できれば
証明書を自動で発行されて、記載されるのは CNAMEのみ。
証明書は 90日単位で細かく更新するポリシーだし、
DV証明書の発行専業で割り切っている分、好感が持てます。
心配なのは、dyndns.org みたいに普及した頃に買収されて、
変な感じになっちゃわないかということかなぁ
Re: (スコア:0)
まあ、これからは暗号化接続がデフォルトでこれまでの平文サイトと同じように扱われて、
本当の意味で必要なサイトはEV証明書を使う、といったことになっていくのかも。
すべての主要ブラウザが標準で対応 (スコア:0)
しかし、JDK は対応してなくて、Javaのクライアントでアクセスすると、証明書の問題でアクセス失敗したのだった。
やっぱり Javaはオワコンなんだなと思った瞬間だった。
Re: (スコア:0)
Let's Encryptの証明書を使ったHTTPSのサイトにJavaアプレットを設置しても、動かない(クラスファイルやJARのロードすらできない)んだろうか。それともブラウザ上ではURLConnectionの処理をブラウザに委譲していて大丈夫なんだろうか。
Javaアプレットとかオワコンもいいところだけど。
Re:すべての主要ブラウザが標準で対応 (スコア:1)
Java アプレットは、NPAPIと共に永眠するはずなんで、どうでもいいと思うけど、
Javaで書かれている Jenkins で、Let's Encrypt で SSL にしたサーバにファイルをアップロードしようと
するとエラーになるんですよ。
クラウド上の開発サーバへのアクセスは DV証明書で十分なんで、
対応して欲しいところなんだけど。
Re: (スコア:0)
Javaの証明書ストアにISRG rootを追加ですかね。それならオレオレでいいじゃんというツッコミは受け付ける。
Cent0S 6.x だと面倒 (スコア:0)
実行に Python 2.7 が必要なんで、
Python 2.6 しか入っていない、CentOS 6.x 系だと色々面倒です。
CentOS 6.x で試そうと思っているひとは、ググって情報収集してから
始めることを推奨します。
Re:Cent0S 6.x だと面倒 (スコア:1)
System Requirements [readthedocs.org]を見ると「The Let’s Encrypt Client presently only runs on Unix-ish OSes that include Python 2.6 or 2.7; Python 3.x support will be added after the Public Beta launch. 」と書いてあるんですが、Python 2.6だと駄目だったんですか？
Re: (スコア:0)
あ、public beta から大丈夫になったのかな。
closed beta 終了直前にやったときは、物騒なメッセージが出てたんで、
数日じゃ流石に変わらないだろうと思って書いたんだけど。
＃ 無視オプションみたいなのを付けて強行すればいけたんかしらん？
Re: (スコア:0)
GitHubのPRを眺めた限りだと、Python 2.6サポートはいちおう追加されたけどあまりにも頻繁に壊れるので--debugオプションを(つまりコケたとき何が起きたかわかるようにすることを)必須にしたようだ。警告メッセージの中に「--debugつけてやり直せ」という趣旨のことが書かれてなかった?
Re: (スコア:0)
サイト管理者がroot持っていないサーバーでも使うような方法がほしいなあ。なんかプラグイン書くとか標準でもmanual plug-inというのがついていて最悪手動で証明書をインストールとかもできるみたいだけど。
次は (スコア:0)
S/MIME用の同様なサービスやってくれないかな。
陰謀を感じる (スコア:0)
HTTPSを訴える企業が裏で提携してて無料で証明書をばらまいたあと普通に証明書買うより高い金額で訴える展開があったりして
Re: (スコア:0)
なんでも男根に見えるおばさんと同じタイプの人ですね。
Re: (スコア:0)
無料の証明書自体は前からありますよ
https://www.startssl.com/ [startssl.com]
Re: (スコア:0)
ここ、非商用利用に限られるのと、破棄証明書の発行にお金を取るというビジネスモデルなのが……。
後、ログイン用の証明書が一年有効で、おまけに発行したドメイン証明書も一年で切れるので、更新がややこしくなったりする。
Re: (スコア:0)
> 破棄証明書の発行にお金を取る
HeartBleedのときこれですごい騒ぎになったねえ。
Re: (スコア:0)
そんな展開はありえない
別のところで証明書を再発行してもらうだけで解決します
Re: (スコア:0)
あんまり関係ないのでは？
あの特許がHTTPSを使ったサイトに対して有効ならすでに金づるが世界中にあふれているわけですからね。
これ以上増やすと一生かかっても裁判が終わらなくなる。
Re:ワイルドカードは非対応？ (スコア:1)
方式的に、サブドメインごとに所有確認をすることになっているから、対応していない、ということなのではないかと。
複数のCNAMEをリクエストするとそれぞれに対して所有確認が求められるので。