web-dev-qa-db-ja.com

このLet's Encrypt CAAバグで何が起こっていましたか？

最近、Let's Encryptは、クライアントで証明書の問題につながるシステムで発生したこのバグを共有しました。彼らはこのようにバグを説明しています：

バグ：証明書の要求にCAAの再チェックが必要なN個のドメイン名が含まれている場合、Boulderは1つのドメイン名を選択してN回チェックしていました。これが実際に意味することは、サブスクライバーがX時にドメイン名を検証し、X時にそのドメインのCAAレコードがLet's Encrypt発行を許可した場合、そのサブスクライバーはX + 30までそのドメイン名を含む証明書を発行できるということです。誰かが後でそのドメイン名にLet's Encryptによる発行を禁止するCAAレコードをインストールした場合でも、.

これは、ユーザーがCAの再チェックを必要とする複数のドメイン名を持っている場合、Let's Encryptは最初のドメインのみをチェックすることを意味しますか？証明書が、ユーザーが所有していないドメインで発行されたという問題は、証明書を取得していたのですか？

bugcaa-record
3
Sara Chipps

Let's Encryptはバグに基づいて安全性の低い証明書を発行しました。それは何よりも競合状態です。

[〜＃〜] caa [〜＃〜] レコードは、ドメインの証明書を発行できる証明書プロバイダーを制限するオプションのDNSレコードです。したがって、サブスクライバーがXにドメイン名を検証し、ドメインのCAAレコードが許可されている場合、サブスクライバーがドメインを検証している間にLet's Encryptの発行を行うと、サブスクライバーは検証日から30日以内に有効な証明書を発行します。 。したがって、誰かが後でX + 30日の間のいつでもLE証明書の発行を禁止するCAAレコードを追加した場合、サブスクライバーはCAAレコードを無視して証明書を発行できます。

バグのある [〜＃〜] pr [〜＃〜] を見ると、これはNewAuthorizationSchema機能フラグが製品で有効にされたときに最初にトリガーされた場所です。

問題のコードは、Goの よくある間違い です。boulder-raの関連コードを参照してください。

// authz2ModelMapToPB converts a mapping of domain name to authz2Models into a
// protobuf authorizations map
func authz2ModelMapToPB(m map[string]authz2Model) (*sapb.Authorizations, error) {
    resp := &sapb.Authorizations{}
    for k, v := range m {
        // Make a copy of k because it will be reassigned with each loop.
        kCopy := k
        authzPB, err := modelToAuthzPB(&v)
        if err != nil {
            return nil, err
        }
        resp.Authz = append(resp.Authz, &sapb.Authorizations_MapElement{Domain: &kCopy, Authz: authzPB})
    }
    return resp, nil
}

問題は、ループイテレータ変数への参照を取得することです。2番目のループイテレータ変数vを適切に処理できませんでした。

そして、この関数の2つの重要なフィールド、IdentifierValueとRegistrationIDの検討に失敗しました

func modelToAuthzPB(am *authzModel) (*corepb.Authorization, error) {
    expires := am.Expires.UTC().UnixNano()
    id := fmt.Sprintf("%d", am.ID)
    status := uintToStatus[am.Status]
    pb := &corepb.Authorization{
        Id: &id,
        Status: &status,
        Identifier: &am.IdentifierValue,
        RegistrationID: &am.RegistrationID,
        Expires: &expires,
    }

Boulder （特にboulder-ra）は、特定のFQDNにCAAの再チェックが必要であり、上記のコミットが原因で不正だった認証オブジェクトのIDフィールドを使用することを決定します。したがって、識別子フィールドの処理方法は、単一のマップのすべての値で同じになります。したがって、たとえば、CAAの再チェックを必要とする複数の承認がある場合、boulder-raは1つのFQDNのみを再チェックし、他のFQDNは再チェックしません。

確かに悪いバグです。

4
Peter Kay