All’interno di un browser Web, è ansible che JavaScript ottenga informazioni sul certificato HTTPS utilizzato per la pagina corrente?

Esiste un metodo per JavaScript in esecuzione in un browser per determinare quale certificato CA viene utilizzato per autenticare l’host remoto per la connessione HTTPS corrente del browser e anche ottenere le proprietà di tale certificato, come il nome della CA?

In caso contrario, ci sono altre opzioni per ottenere in modo programmatico queste informazioni, come ActiveX, Java, CGI sul lato server, …?

Puoi usare il progetto opensource Forge per farlo. Implementa SSL / TLS in JavaScript. È ansible effettuare una chiamata Ajax al server e utilizzare una richiamata per ispezionare il certificato. Tieni presente che il server è quello che invia il codice JavaScript, quindi questo non dovrebbe essere usato per determinare se ti fidi o meno del server da cui proviene JavaScript. Il progetto Forge consente le richieste tra domini, quindi se lo si utilizza per la fiducia, è ansible caricare il file Forge JavaScript da un server già affidabile e quindi contattare il server che non si è ancora fidato. Tuttavia, a meno che quell’altro server non disponga di una norma interdominio, non sarà ansible eseguire la richiesta interdominio.

https://github.com/digitalbazaar/forge/blob/master/README.md

I collegamenti del blog nel README forniscono ulteriori informazioni su come Forge può essere utilizzato e come funziona.

JavaScript in esecuzione nel browser web non ha accesso alle informazioni del certificato. Anche le informazioni sul certificato non vengono passate tramite HTTP all’applicazione. La mia ricerca indica che non c’è modo per l’applicazione web per determinare se un attacco man-in-the-middle ha iniettato un certificato falso da qualche parte tra l’host e il client.

AFAIK non con Javascript da solo. Ma alcuni server Web ti consentono di accedere ai parametri di connessione del thread o del processo. Uno script serveride può quindi inviare tali valori insieme alla richiesta e lo si utilizza.

Ho trovato questo per nginx webserver: http://wiki.nginx.org/NginxHttpSslModule (guarda la parte inferiore della pagina per le variabili). Dovrebbe essere ansible impostarli come variabili di ambiente e passarli ai tuoi processi FastCGI o qualsiasi altra cosa tu usi.

AOLServer / Naviserver consente un accesso simile con il modulo nsssl.

No. Potresti ovviamente farlo con AJAX / ActiveX / Java / Flash / Silverlight e uno script sul lato server personalizzato, ma non riesco a capire perché ne avresti bisogno.


EDIT: L’idea di cui sopra è che si farebbe una richiesta di rete (utilizzando una delle tecnologie di cui sopra) al server e chiedere quale certificato è stato utilizzato per quella richiesta di rete. Il server potrebbe quindi ispezionare la propria configurazione e rispondere alla domanda.

Se il browser in qualche modo si fida di un certificato non valido e si connette al server sbagliato (ad esempio un server MITM), il server potrebbe mentire. Una volta che il meccanismo di fiducia del browser è stato compromesso, non so come evitarlo.

Per quanto ne so, non c’è modo (usando esclusivamente API lato client) per chiedere direttamente al browser che cosa sta usando “per la connessione SSL corrente del browser”. Anche Forge non lo fa. Crea una sessione SSL completamente parallela , ma non ti consente di chiedere informazioni sulla sessione SSL nativa del browser.

Copia della mia risposta da C’è un modo per accedere alle informazioni sul certificato da un’estensione di Chrome

Risposta 2018: sì, in Firefox 62

Avrai bisogno di creare una estensione Web, che è anche chiamata estensione del browser.

Vedi l’ accesso alle informazioni di sicurezza su MDN

Puoi anche consultare i documenti per:

  • GetSecurityInfo
  • Informazioni di sicurezza
  • CertificatoInfo .

Avrai bisogno di Firefox 62.

Ecco un background.js funzionante

 var log = console.log.bind(console) log(`\n\nTLS browser extension loaded`) // https://developer.chrome.com/extensions/match_patterns var ALL_SITES = { urls: [''] } // Mozilla doesn't use tlsInfo in extraInfoSpec var extraInfoSpec = ['blocking']; // https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/onHeadersReceived browser.webRequest.onHeadersReceived.addListener(async function(details){ log(`\n\nGot a request for ${details.url} with ID ${details.requestId}`) // Yeah this is a String, even though the content is a Number var requestId = details.requestId var securityInfo = await browser.webRequest.getSecurityInfo(requestId, { certificateChain: true, rawDER: false }); log(`securityInfo: ${JSON.stringify(securityInfo, null, 2)}`) }, ALL_SITES, extraInfoSpec) log('Added listener') 

manifest.json :

 { "manifest_version": 2, "name": "Test extension", "version": "1.0", "description": "Test extension.", "icons": { "48": "icons/border-48.png" }, "background": { "scripts": ["background.js"] }, "permissions": [ "webRequest", "webRequestBlocking", "" ] } 

inserisci la descrizione dell'immagine qui

Può anche essere implementato in Chromium una volta che questo codice viene unito .

In termini pratici, questo ha poco senso: perché dovresti conoscere le informazioni del certificato da JavaScript sulla singola pagina già visualizzata?

  • Se non è attendibile, ovviamente anche il tuo codice potrebbe essere stato alterato, quindi non ci si può fidare neanche di questo.

  • Se il certificato è effettivamente attendibile, in che modo sarebbe ansible distinguere lo scenario da quello in cui il certificato non è attendibile, ma il tuo codice è stato modificato tramite un attacco MitM per pensare diversamente?

Pertanto, il controllo dei certificati sarebbe utile solo dalle estensioni del browser (che si presume siano codice attendibile) rispetto agli script nelle singole pagine stesse. Tale interfaccia che le estensioni utilizzano è specifica per il browser e non tutti i browser lo forniscono. Ad esempio, mentre i browser Mozilla ti permettono di dare un’occhiata ai certificati (con estensioni come l’ osservatorio EFF SSL ), Chromium è ancora carente .