I nuovi gTLD stanno arrivando. In che modo i browser gestiranno cookie, SOP e certificati?

2

Dato che la "zona" di sicurezza varia in base al TLD, come verrà gestito il nuovo TLS?

Ad esempio: un browser può consentire la condivisione di cookie e certificati SSL e certificati jolly

  • company.com (due livelli di profondità)
  • company.co.uk (tre livelli di profondità)
  • local (profondità di un livello)

Tuttavia, i cookie, le richieste cross-site e altro sono vietati dai browser in quanto tutti si applicano in modo troppo generico ai TLD

  • *.com (due livelli di profondità)
  • *.co.uk (tre livelli di profondità)

Domanda:

  1. Con i nuovi TLD proposti, quale sarà il nuovo ambito di sicurezza per i certificati jolly e SOP? Dove è pubblicato?

  2. È previsto che SOP e l'ambito dei certificati jolly siano uguali?

  3. Ci sono altri dubbi oltre ai certificati SSL e SOP che si applicano ai cookie, alle richieste cross-site, javascript, localstorage, Flash, ecc.

Aggiornamento:

Poiché non esiste alcuna possibilità che ogni CA supporti la stessa politica durante l'emissione dei certificati e SOP dipenda in realtà da tutti i browser che ottengono un consenso, come faranno i browser a gestirli?

    
posta random65537 12.08.2013 - 19:36
fonte

4 risposte

2

I SOP e i certificati jolly sono problemi ortogonali. SOP lavora sui nomi trovati nell'URL e non si preoccupa di ciò che è apparso in un certificato che potrebbe essere o meno coinvolto in qualche punto. Se uno script proviene da un URL in https://foo.example.com/ , https://bar.example.com/ sarà considerato come "origine" distinta, anche se entrambi utilizzano lo stesso certificato con foo.example.com e bar.example.com in esso (o, equivalentemente, un carattere jolly nome *.example.com ).

I browser esistenti utilizzano regole restrittive non documentate su quali nomi di caratteri jolly sono consentiti. Vedi, ad esempio, questo domanda precedente . Una regola frequente è che i caratteri jolly di primo e secondo livello non sono consentiti (quindi non *.com ); i nuovi TLD non cambieranno nulla in questo. La parte difficile è per i nomi "a due livelli" che agiscono funzionalmente come TLD, ad es. %codice%. I nuovi TLD sono, per la maggior parte, un modo per evitare tali pseudo-TLD a due livelli, quindi ci si aspetta che questo possa incorrere in problemi meno , non > più .

Tutti questi giochi sui certificati con caratteri jolly sono solo per SSL / TLS e non hanno alcun impatto a livello HTTP; SOP, i cookie ... non si preoccupano dei nomi di caratteri jolly.

(A meno che un fornitore di browser non diventi davvero creativo, come a volte fanno.)

    
risposta data 12.08.2013 - 20:41
fonte
1

In realtà non è fondamentalmente diverso da quello che è adesso. Sarebbe davvero compito dell'AC decidere sulle proprie politiche per assicurarsi che non emettano un certificato più ampio rispetto all'entità che richiede i controlli del certificato. Sta cercando di abbinare il carattere jolly al nome del dominio nel certificato per vedere se corrisponde. Dovrebbero determinare ciò in base a ciascuna zona e in che modo i nomi di dominio sono allocati in quella zona.

    
risposta data 12.08.2013 - 19:51
fonte
1

È a mia conoscenza che i certificati con caratteri jolly supportano solo un singolo livello di corrispondenza dei sottodomini . Ciò significa che non puoi avere corrispondenze come *.*.com o *.*.stackexchange.com . Credo che tecnicamente possiedi certificati con caratteri jolly come *.com , anche se nessuna autorità di certificazione dovrebbe rilasciare tali certificati (e corrisponderebbero solo per dire google.com e non corrispondono a www.google.com ).

Garantito RFC-6125 sembra indicare che le posizioni consentite del carattere jolly nei certificati jolly usati per non essere chiari e coerentemente definiti attraverso i browser. Tuttavia, fornisce regole chiare su come farlo :

Se un client corrisponde all'identificatore di riferimento rispetto a un presentato    identificatore la cui parte del nome di dominio DNS contiene il carattere jolly    carattere '*', si applicano le seguenti regole:

  1. Il client NON DEVE tentare di abbinare un identificatore presentato in    che il carattere jolly comprende un'etichetta diversa dalla    l'etichetta più a sinistra (ad esempio, non corrisponde alla barra. *. esempio.net).

  2. Se il carattere jolly è l'unico carattere di sinistra    etichetta nell'identificatore presentato, il cliente NON DEVE confrontare    contro tutto tranne l'etichetta più a sinistra del riferimento    identificatore (ad esempio, * .example.com corrisponderebbe a foo.example.com ma    non bar.foo.example.com o example.com).

  3. Il client può abbinare un identificatore presentato in cui il carattere jolly    il carattere non è l'unico carattere dell'etichetta (ad es.    baz * .example.net e * baz.example.net e b * z.example.net farebbero    essere preso per abbinare baz1.example.net e foobaz.example.net e    buzz.example.net, rispettivamente). Tuttavia, il cliente NON DEVE    tenta di abbinare un identificatore presentato in cui il carattere jolly    il carattere è incorporato all'interno di un'etichetta A o etichetta U [IDNA-DEFS] di    un nome di dominio internazionalizzato [IDNA -

risposta data 12.08.2013 - 19:55
fonte
1

L'uso della lista suffissi pubblici rende questo relativamente facile, poiché questo elenco non cambia molto spesso.

Questo è un elenco di tutti i domini di primo e secondo livello in base ai quali le persone possono acquistare un nome di dominio. Quindi un browser deve abbinare un solo livello oltre la voce corrispondente in questo elenco per determinare il nome di dominio che dovrebbe usare come origine.

Questo è stato supportato in Firefox per un po 'di tempo , e Mozilla ha reso l'elenco aperto a chiunque voglia usarlo.

    
risposta data 13.08.2013 - 02:19
fonte

Leggi altre domande sui tag