È possibile emettere un certificato SSL con caratteri jolly per un dominio di secondo livello?

Sì, può essere emesso.

Fortunatamente i browser comuni non accettano i certificati jolly per i TLD.

Codice sorgente Chromium :

// Do not allow wildcards for public/ICANN registry controlled domains -
// that is, prevent *.com or *.co.uk as valid presented names, but do not
// prevent *.appspot.com (a private registry controlled domain).
// In addition, unknown top-level domains (such as 'intranet' domains or
// new TLDs/gTLDs not yet added to the registry controlled domain dataset)
// are also implicitly prevented.
// Because |reference_domain| must contain at least one name component that
// is not registry controlled, this ensures that all reference domains
// contain at least three domain components when using wildcards.
size_t registry_length =
    registry_controlled_domains::GetCanonicalHostRegistryLength(
        reference_name,
        registry_controlled_domains::INCLUDE_UNKNOWN_REGISTRIES,
        registry_controlled_domains::EXCLUDE_PRIVATE_REGISTRIES);

// ... [SNIP]

// Account for the leading dot in |reference_domain|.
bool is_registry_controlled =
    registry_length != 0 &&
    registry_length == (reference_domain.size() - 1);

// Additionally, do not attempt wildcard matching for purely numeric
// hostnames.
allow_wildcards =
    !is_registry_controlled &&
    reference_name.find_first_not_of("0123456789.") != std::string::npos;
}

L'elenco completo dei domini che Google non consente è net/base/registry_controlled_domains/effective_tld_names.dat

Anche altri browser lo fanno, inclusi IE e Firefox.

Nell'elenco dei certificati falsi emessi da DigiNotar , c'è " *. *. com". Questo è ovviamente un tentativo di aggirare la restrizione.

Per la parte emissione , è possibile inserire tutto in un certificato. Che un nome sia "jolly" non ha alcun significato speciale per la CA. La CA mette una stringa come dNSName in un'estensione Subject Alt Name , e il gioco è fatto. Se questa stringa contiene caratteri " * " o meno non avrà alcun impatto sul comportamento della CA.

Ciò che importa è ciò che i client SSL accetteranno come "certificato valido", cioè un certificato che include un nome che "corrisponde" al nome del server previsto (quello incluso nell'URL). Questo è nominalmente specificato in RFC 2818, sezione 3.1 e consente molti tipi di nomi di caratteri jolly, incluse le cose come " www.*.*c* ", facendo corrispondere (teoricamente) qualsiasi nome server contenente tre componenti, il primo è " www " e il terzo contiene almeno un " c ". I fornitori di browser Web hanno presto considerato questa specifica:

• consentito per nomi di caratteri jolly molto ampi;
• era relativamente complesso da implementare correttamente;
• è improbabile che sia implementato correttamente da entrambi gli altri produttori di browser e da CA (anche se la CA non è influenzata dal contenuto del nome, è ancora responsabile del contenuto del certificato, e i produttori di browser hanno indovinato correttamente che ci sarebbe stato CA che rilascerebbe involontariamente certificati con caratteri jolly eccessivi);
• era comunque una RFC "informativa", non uno "standard proposto", quindi le menti inclini agli avvocati potrebbero sostenere che potrebbe essere ignorata.

Quindi i fornitori di browser hanno creato i propri schemi e restrizioni. Molto più tardi, è stata pubblicata una nuova RFC (6125, da marzo 2011), con sezione 6.4.3 dedicata all'elaborazione dei nomi di caratteri jolly nei certificati. Quello che descrive RFC 6125 è più in sintonia con la realtà, e è uno "standard proposto", quindi c'è almeno un po 'di volontà, a un certo livello, per farlo accadere. Tuttavia, nulla in RFC 6125 richiede il rifiuto di *.com ; tuttavia i browser fanno rifiutano.

L'ho provato su browser comuni, i tre grandi (su Windows comunque) non lo accettano. Quello che non ho fatto è provarlo sulle piattaforme mobili che sono il vero obiettivo di questo attacco. Poiché iOS non ha un modo per revocare i certificati, ci sono milioni di dispositivi i che sono vulnerabili finché Apple non rilascia una patch e la applicano.

Luoghi ovvi per provare questo con alto impatto: Activesync per lo scambio, client VPN ssl, safari su idevices, browser di serie su androidi.