Vraag Kan JavaScript in een webbrowser informatie verkrijgen over het HTTPS-certificaat dat voor de huidige pagina wordt gebruikt?


Is er een methode voor het uitvoeren van JavaScript in een browser om te bepalen welk CA-certificaat wordt gebruikt om de externe host voor de huidige HTTPS-verbinding van de browser te verifiëren en om ook eigenschappen van dat certificaat te verkrijgen, zoals de naam van de CA?

Zo nee, zijn er andere opties om deze informatie, zoals ActiveX, Java, CGI aan de serverzijde, ...? Te verzamelen?


14
2018-03-08 14:51


oorsprong


antwoorden:


U kunt de opensource gebruiken Smeed project om dit te doen. Het implementeert SSL / TLS in JavaScript. U kunt een ajax-oproep naar de server doen en een callback gebruiken om het certificaat te inspecteren. Houd er rekening mee dat de server degene is die het JavaScript verzendt, dus dit moet niet worden gebruikt om te bepalen of u de JavaScript-server vertrouwt. Het Forge-project staat interdomeinverzoeken toe, dus als u dit voor vertrouwen gebruikt, kunt u Forge JavaScript laden van een server die u al vertrouwt en vervolgens contact opnemen met de server die u nog niet vertrouwt. Als die andere server echter geen interdomeinbeleid biedt, kunt u het domeinoverschrijdende verzoek niet uitvoeren.

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

De bloglinks in README geven meer informatie over hoe Forge kan worden gebruikt en hoe het werkt.


16
2017-08-31 17:04



JavaScript dat wordt uitgevoerd in de webbrowser heeft geen toegang tot de certificaatinformatie. De certificaatinformatie wordt ook niet via HTTP doorgegeven aan de toepassing. Mijn onderzoek geeft aan dat de webapplicatie geen mogelijkheid biedt om te bepalen of een man-in-the-middle-aanval ergens tussen de host en de klant een nepcertificaat heeft geïnjecteerd.


2
2018-05-04 14:18



AFAIK niet alleen met Javascript. Maar sommige webservers bieden u toegang tot de verbindingsparameters van de thread of het proces. Een serverside-script kan vervolgens die waarden samen met het verzoek verzenden en gebruiken.

Ik vond dit voor nginx webserver: http://wiki.nginx.org/NginxHttpSslModule (Kijk naar de onderkant van de pagina voor de variabelen). Het moet mogelijk zijn ze in te stellen als omgevingsvariabelen en deze door te geven aan uw FastCGI-processen of wat u ook gebruikt.

AOLServer / Naviserver biedt vergelijkbare toegang met de nsssl-module.


1
2018-03-08 15:11



Nee. Je zou het duidelijk kunnen doen met AJAX / ActiveX / Java / Flash / Silverlight en een aangepast server-side script, maar ik begrijp niet waarom je dit nodig zou hebben.


EDIT: Het bovenstaande idee is dat je een netwerkverzoek (met behulp van een van de bovenstaande technologieën) naar de server zou sturen en zou vragen welk certificaat werd gebruikt voor dat netwerkverzoek. De server kan dan zijn eigen configuratie inspecteren en de vraag beantwoorden.

Als de browser op een of andere manier een ongeldig certificaat vertrouwt en verbinding maakt met de verkeerde server (bijvoorbeeld een MITM-server), zou de server kunnen liegen. Zodra het vertrouwensmechanisme van de browser is aangetast, weet ik niet hoe ik dat moet vermijden.

Voor zover ik weet, is er geen manier (puur gebruik van client-side API's) om de browser rechtstreeks te vragen welk certificaat hij gebruikt "voor de huidige SSL-verbinding van de browser". Zelfs Forge doet dat niet. Het creëert een geheel parallel SSL-sessie, maar het laat u niet vragen naar de oorspronkelijke SSL-sessie van de browser.


1
2018-03-08 14:53



Mijn eigen antwoord kopiëren van Is er een manier om toegang te krijgen tot certificaatinformatie van een Chrome-extensie?

2018 antwoord: ja, in Firefox 62

U moet een WebExtension maken, die ook een browserextensie wordt genoemd.

Zien toegang tot beveiligingsinformatie op MDN

U kunt ook de documentatie bekijken voor:

U hebt Firefox 62 nodig.

Hier is het werken background.js

var log = console.log.bind(console)

log(`\n\nTLS browser extension loaded`)

// https://developer.chrome.com/extensions/match_patterns
var ALL_SITES = { urls: ['<all_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",
        "<all_urls>"
    ]
}

enter image description here

Het kan ook een keer in Chromium worden geïmplementeerd deze code is samengevoegd.


0
2018-05-23 09:26



In praktische termen heeft dit weinig nut - waarom zou u certificaatinformatie van JavaScript op de website moeten weten? individuele pagina al gerenderd?

  • Als het niet vertrouwd is, dan is je code natuurlijk ook veranderd, dus het kan ook niet vertrouwd worden.

  • Als het certificaat daadwerkelijk wordt vertrouwd, hoe zou u dan het scenario kunnen onderscheiden van het scenario waarin het certificaat niet wordt vertrouwd, maar uw code is gewijzigd via een MitM-aanval om anders te denken?

Het controleren van certificaten zou dus alleen van binnen nuttig zijn Browser-extensies (die worden verondersteld te zijn vertrouwde code) in tegenstelling tot de scripts in de individuele pagina's zich. Een dergelijke interface die extensies gebruiken is browserspecifiek en niet alle browsers bieden deze zelfs. Bijvoorbeeld, terwijl Mozilla-browsers je de certificaten laten zien (extensies zoals het EFF SSL-observatorium) Chromium ontbreekt nog steeds.


-3
2018-02-04 02:08