Ottenere e quindi distribuire un certificato SSL con caratteri jolly - va bene?

Question

Ottenere e quindi distribuire un certificato SSL con caratteri jolly - va bene?

#1 da (2 voti)

2

Ho un'idea stupida / folle che volevo chiedere qui. Probabilmente non funzionerà, ma sono curioso.

La sicurezza del browser non consentirà socket Web insicuri (ws: //) da pagine protette (https: //) per vari motivi. Mi piacerebbe creare un'app che permetta ai siti Web sicuri di accedere a molte cose diverse via WS, e non voglio dover creare certificati SSL per tutto.

...

Pazzo hack: ottieni un certificato con caratteri jolly per un dominio (ad esempio insecureashell.net) e configura server DNS per servire gli IP codificati nei nomi host sotto quel dominio. Quindi, ad esempio 1.1.1.1.insecureashell.net si risolverebbe in 1.1.1.1.

Quindi distribuisci la chiave privata per questo certificato jolly ovunque, consentendo a tutte le app di essere visualizzate come "sicure" dai browser che effettuano connessioni wss: //1.1.1.1.insecureashell.net/. / p>

I'm assumendo questo viola un qualche tipo di politica di gestione cert nelle regole CA https e otterrebbe revocato questo certificato, ma non riesco a trovare nulla a questo effetto. Non riesco nemmeno a pensare a una ragione per cui è intrinsecamente cattiva, dal momento che si applicherebbe solo a questo specifico dominio "phony SSL" e da nessun'altra parte sulla rete. Le intestazioni CORS potrebbero essere utilizzate per consentire o negare questo, ecc.

Quindi perché non funziona? :)

Modifica: forse lo farà. Apparentemente esistono certificati SSL privati per domini che risolvono in 127.0.0.1 su GitHub: link

web tls websocket

posta Adam Ierymenko 21.01.2017 - 00:00

fonte

1 risposta

Leggi altre domande sui tag web tls websocket

Spoofing dell'identità di un altro utente in Telegram Come assicurarsi che una nuova chiave si sia propagata

score 2 · Answer 1

L'esempio specifico che utilizzi non funzionerà, perché contiene più livelli di sottodomini e i certificati jolly sono validi solo per un singolo livello. Quindi un certificato per *.insecureshell.net funzionerà per 1.insecureshell.net e 2.insecureshell.net , ma non 1.1.insecureshell.net , e certamente non 1.1.1.1.insecureshell.net . Tuttavia, ciò non significa che una variazione su questo non può funzionare, almeno assumendo che controlli effettivamente 1.1.1.1 e dica 4.3.2.1 come esempi.

HTTPS e certificati non si preoccupano dell'indirizzo IP sottostante, si preoccupano solo che il nome soggetto o il nome alternativo di un soggetto nel certificato corrispondano al nome host del sito a cui stai tentando di connettersi. Per un certificato jolly, ciò significa qualsiasi sottodominio a livello singolo. Quindi, se controlli questi due indirizzi IP, ed è qui che stai ospitando i tuoi servizi, potresti utilizzare i seguenti sottodomini: 1-1-1-1.insecureshell.net e 4-3-2-1.insecureshell.net per farli riferimento. Quindi hai semplicemente voci DNS per quei due sottodomini che puntano rispettivamente agli indirizzi IP 1.1.1.1 e 4.3.2.1 , e installa il tuo certificato wildcare su entrambe le macchine. Non c'è davvero alcun motivo per farlo, in generale. Invece tu usi service1.insecureshell.net e service2.insecureshell.net , e hai voci DSN per quei nomi puntati su 1.1.1.1 e 4.3.2.1 , e ancora una volta, installa il tuo certificato jolly su entrambe le caselle, e sei a posto.