3

StartSSLに、自分が所有するドメインの証明書を持っています。だからこれは私に与えます：

  • 中間CA証明書
  • StartComルートCA証明書
  • 秘密鍵

これらを受け取るために、私はStartSSLにこれを送信しました：

  • 私が所有している証明mydomain.com（電子メールコードの検証による）
  • すでに持っている秘密鍵から作ったCSR

サーバー上のOpenSSLがそれらを使用してWebブラウザーを安心させることができるように、このキーとこの証明書チェーンをサーバーに配置する必要があるようです。

しかし、どの秘密鍵はどれですか？CSRを生成した秘密鍵とCAから取得した秘密鍵を持っています。

私も100％はっきりしていないのは、ここで何が保証されているかということです。ブラウザは証明書を確認します。証明書は、に接続する必要があることをブラウザに通知しmydomain.comます。

StartComが知っているのは、私が所有していることを彼らに示したということmydomain.comだけであり、この秘密鍵を持っているのは私だけです。これが受け継がれているので、ユーゴスラビアから接続しているブラウザにもこの情報があります。

したがって、私のWebサーバーは、動的IPを使用した安価なホーム接続上にあります。ドメインレジストラでDNSをに直接使用するmydomain.comように設定しましたが、ダイナミックDNSサービスが自宅のルーターのダイナミックWANIPにリダイレクトされました。myname.dynDNSProvider.comCNAMEmyname.dynDNSProvider.com

IPが変更されると、リクエストは他の誰かに送信されるか、まったく送信されません。攻撃者は、を報告する有効な証明書を使用してサーバーをセットアップできないため、すべて問題ありませんmydomain.com。また、DNSサービスも信頼する必要があります。IPを更新すると、すべてが再び機能します。

それで、これはそれがどのように機能するのですか？ドメインから実際のIPへのリダイレクトパスはSSL認証の目的に関係ありませんか？私のDNSサービスプロバイダーは、そのように選択した場合、部外者よりも効果的に攻撃を実行できますか？

私は基本的に、安価な場所でホームサーバーへの安全な接続を設定しようとしています。安価な場所でそれを実現するために、ダイナミックDNSによって発生する短いダウンタイムはまったく問題ありません。ここで解決しようとしている特定の問題は、ブラウザに「無効な証明書!!!」と言わないようにすることです。彼らが私のサーバーから私の自己署名SSL証明書を見るとき。このようなものがどのように機能するかを学ぶための良いリソースを見つけるのに少し苦労しています。

4

1 に答える 1

3

しかし、どの秘密鍵はどれですか？CSRを生成した秘密鍵とCAから取得した秘密鍵を持っています。

CAから公開鍵を取得しました。その公開鍵とは、CSRの一部である公開鍵と、基本的に「これを検証した」という意味のCACertからの証明書です。単純化していますが、それが要点です。持っている秘密鍵と、それらから取得した公開鍵を含む証明書を使用します。

DNSビットに関しては、証明書に書かれているのは「大丈夫ですexample.com」です。Webブラウザーがに接続しようとしていて、サーバーにブラウザーのトラストストア（CACertはMozillaストアとMicrosoftストアの両方にあります）の証明書によってexample.com有効で署名された証明書がある場合は、設定されています。example.com証明書にIPアドレスが含まれていない限り、接続によってどのIPアドレスが生成されるかは重要ではありません（これは標準的な方法ではありません。CACertはsubjectAltNamesがDNS名のみに設定された証明書を発行します）。

私のDNSサービスプロバイダーは、そう選択した場合、

あなたはあなたの質問を引きずったので、答えるのは少し難しいです。しかし、あなたの「DNSプロバイダー」（私はあなたがdyndnsサービスを意味すると思います）は3つのことをすることができます：彼ら自身のサーバーにトラフィックを送る、どこにもそれを送らない、またはそれを傍受した後にあなたにそれを送る。そこでの攻撃に個別に対処しましょう。

まず、トラフィックを自分のサーバーに送信します。ドメインの有効な証明書を取得できず、すべての接続にSSLが必要な場合（ユーザーが非SSL要求を発行することはありません）、これは役に立ちません。偽造された証明書は無効として表示され、ゲームは終了します。

次に、トラフィックをどこにも送信しません。サービス拒否。この文脈では面白くない。

第三に、 man-in-the-middle攻撃を試みます。ここでの問題は、クライアントが送信するトラフィックは、あなたの秘密鍵を持っている人だけが読み取ることができるということです-彼らは持っていません。したがって、ドメインの有効な証明書を取得して、その証明書を提示できない限り、途中にいてトラフィックを読み取ることができない可能性があります。したがって、この攻撃は実際には最初の証明書に要約されます。あなたはかなり安全です。

于 2012-07-17T05:00:58.943 に答える