Security Professionals
- ipfw add deny all from eindgebruikers to any
Cert revocation check ellende
Firefox is bij mij zo ingesteld dat https verbindingen worden geweigerd als er geen fatsoenlijke certificate revocation check kan worden uitgevoerd.
Gisteren had ik er al meermaals last van dat ocsp.comodoca.com geen antwoord gaf, en daardoor alle xs4all.nl https sites voor mij onbereikbaar waren.
Zojuist probeer ik https://isc.sans.edu te openen en krijg:
Interessant vind ik dat die site OCSP stapling gebruikt. In Wireshark zie ik een TLSv1.2 netwerkpakket met daarin "Certificate, Certificate Status, Server Key Exchange, Server Hello Done".
Het Certificate Status deel bevat:
Zo zie je maar dat, zelfs met OCSP stapling, als jouw CA haar zaken niet voor elkaar heeft, jouw site onbereikbaar wordt voor diegenen die hun browser veilig configureren.
Dit na de ellende van afgelopen week waarbij Thawte, na lang aandringen, eindelijk een code signing certificaat introk dat voor het ondertekenen [*] van malware werd gebruikt, Zie https://www.security.nl/posting/526658/Falen+van+AV+industrie#posting527609 en eerdere bijdragen van mij.
[*] Feitelijk wordt de private key daarvoor gebruikt, en toont de public key in het -als onderdeel van de executable meegeleverde certificaat- aan dat de ondertekenaar in het bezit moet zijn geweest van de private key - maar helaas snappen maar weinigen dit.
Tweede probleem: er zat een fout in de CRL file van Thawte waardoor die revocation aanvankelijk NIET WERKTE. Nadat ik daarover gemaild heb met Microsoft en Thawte, heeft Thawte het probleem kennelijk opgelost (ik heb nog geen tijd gehad om te onderzoeken wat er fout was in de vorige, niet goed werkende, CRL files).
Als je nu http://tl.symcb.com/tl.crl downloadt en installeert, zal de digitale handtekening (type Authenticode) onder bestanden die, na 27 juli 2017 02:00:00 (Nederlandse tijd), met het "Media Lid" (naar verluidt uit Moskou) certificaat zijn ondertekend, als ongeldig worden bestempeld.
Degenen die veel downloaden of op andere wijze risico's lopen met potentiële malware in aanraking te komen, en/of gewoon paranoïde mensen, raad ik aan http://tl.symcb.com/tl.crl te downloaden en te installeren (met de rechter muisknop op het gedownloade bestand klikken, en installeren kiezen). Want als die file de afgelopen weken automatisch is gedownload, dan zal dat de eerste 2 weken na dat moment NIET automatisch opnieuw gebeuren.
Gisteren had ik er al meermaals last van dat ocsp.comodoca.com geen antwoord gaf, en daardoor alle xs4all.nl https sites voor mij onbereikbaar waren.
Zojuist probeer ik https://isc.sans.edu te openen en krijg:
Secure Connection Failed
An error occurred during a connection to isc.sans.edu. The OCSP server suggests trying again later. Error code: SEC_ERROR_OCSP_TRY_SERVER_LATER
An error occurred during a connection to isc.sans.edu. The OCSP server suggests trying again later. Error code: SEC_ERROR_OCSP_TRY_SERVER_LATER
Interessant vind ik dat die site OCSP stapling gebruikt. In Wireshark zie ik een TLSv1.2 netwerkpakket met daarin "Certificate, Certificate Status, Server Key Exchange, Server Hello Done".
Het Certificate Status deel bevat:
TLSv1.2 Record Layer: Handshake Protocol: Certificate Status
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 13
Handshake Protocol: Certificate Status
Handshake Type: Certificate Status (22)
Length: 9
Certificate Status Type: OCSP (1)
Certificate Status
Certificate Status Length: 5
OCSP Response
responseStatus: tryLater (3)
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 13
Handshake Protocol: Certificate Status
Handshake Type: Certificate Status (22)
Length: 9
Certificate Status Type: OCSP (1)
Certificate Status
Certificate Status Length: 5
OCSP Response
responseStatus: tryLater (3)
Zo zie je maar dat, zelfs met OCSP stapling, als jouw CA haar zaken niet voor elkaar heeft, jouw site onbereikbaar wordt voor diegenen die hun browser veilig configureren.
Dit na de ellende van afgelopen week waarbij Thawte, na lang aandringen, eindelijk een code signing certificaat introk dat voor het ondertekenen [*] van malware werd gebruikt, Zie https://www.security.nl/posting/526658/Falen+van+AV+industrie#posting527609 en eerdere bijdragen van mij.
[*] Feitelijk wordt de private key daarvoor gebruikt, en toont de public key in het -als onderdeel van de executable meegeleverde certificaat- aan dat de ondertekenaar in het bezit moet zijn geweest van de private key - maar helaas snappen maar weinigen dit.
Tweede probleem: er zat een fout in de CRL file van Thawte waardoor die revocation aanvankelijk NIET WERKTE. Nadat ik daarover gemaild heb met Microsoft en Thawte, heeft Thawte het probleem kennelijk opgelost (ik heb nog geen tijd gehad om te onderzoeken wat er fout was in de vorige, niet goed werkende, CRL files).
Als je nu http://tl.symcb.com/tl.crl downloadt en installeert, zal de digitale handtekening (type Authenticode) onder bestanden die, na 27 juli 2017 02:00:00 (Nederlandse tijd), met het "Media Lid" (naar verluidt uit Moskou) certificaat zijn ondertekend, als ongeldig worden bestempeld.
Degenen die veel downloaden of op andere wijze risico's lopen met potentiële malware in aanraking te komen, en/of gewoon paranoïde mensen, raad ik aan http://tl.symcb.com/tl.crl te downloaden en te installeren (met de rechter muisknop op het gedownloade bestand klikken, en installeren kiezen). Want als die file de afgelopen weken automatisch is gedownload, dan zal dat de eerste 2 weken na dat moment NIET automatisch opnieuw gebeuren.
Reacties (8)
In aanvuling op het bovenstaande: er zit een onverwachte eigenschap in de Windows Certificate Viewer (W10 Creators Update en, voor zover ik weet, allee eerdere Windows versies).
Dat het certificaat daadwerkelijk is ingetrokken blijkt als volgt. Ik klik met de rechter muistoets op de malware file "1.dat" (na mijn virusscanner te hebben uitgezet en 1.dat uit de versleutelde zip file heb gehaald haal waarin ik deze bewaar), kies Properties (Eigenschappen) en open het tabblad Digital Signatures, zie linksboven in https://imgur.com/a/Vx8WT.
Daarna kan ik "Media Lid" selecteren en middels "View Certificate" de drie verschillende tabbladen van zo'n certificaat bekijken (zie het plaatje).
ECHTER, als ik dat certificaat exporteer naar een bestand (dat ik "Media Lid.cer" heb genoemd), in ik dubbel-klik daarop om dat certificaat te inspecteren, dan blijk UIT NIETS dat vdit certificaat is ingetrokken! Zie https://imgur.com/a/rMHPE.
Conclusie: de certificate viewer in Windows checkt uitsluitend op revocation van een code signing certificaat in de context van een gesigneerd bestand!
De reden hiervoor is vermoedelijk dat Authenticode niet kijkt naar de intrek- en/of verloopdatum van een code signing certificaat; wat telt is de timestamp (de datum en tijd) van ondertekenen. Die timestamp moet wel door een betrouwbare organisatie zijn aangeleverd (en zelf ook weer digitaal zijn ondertekend). Hierdoor kan zo'n code signing certificaat gewoon nog geldig zijn nadat de vervaldatum van het certificaat is gepasseerd. Indien een code signing certificaat is ingetrokken (revoked), is dat certificaat geldig vanaf het moment van uitgeven tot het moment van revocation!
Zonder een signing timestamp weet Windows dus niet of een code signing certificaat geldig is of niet.
Behoorlijk verwarrend wat mij betreft...
P.S. voordat iemand denkt dat ik hierdoor dacht dat de Thawte CRL niet werkte: ik heb wel degelijk steeds getest met "1.dat", zie https://imgur.com/a/UUxVP waar ik in https://www.security.nl/posting/526658/Falen+van+AV+industrie#posting527475 naar verwijs. Ik wist toen al dat de losse certifcate viewer niet deed wat ik verwachtte, ik had er toen alleen nog geen verklaring voor :-)
--------------------------------------------
Aanvulling 14:02 OOPS door mijn eigen verklaring hierboven snap ik nu ook waarom de revocation eind vorige week niet werkte (suf suf suf). Het certificaat was door Thawte ingetrokken per 10 augustus 2017, 00:00:00 en dat is na het zetten van de digitale handtekening onder de malware file "1.dat"!
Als je nu http://tl.symcb.com/tl.crl downloadt staat daarin dat het certificaat is ingetrokken per 27 juli 2017, 02:00:00" in dat is voordat de malware werd ondertekend.
Zie https://imgur.com/a/hbYpr voor de verschillen tussen de beide CRL files (links oud, rechts nieuw).
Het is dus heel belangrijk dat een code signing certificaat wordt ingetrokken net voor het eerst bekende misbruik daarvan, en niet later!
Dat het certificaat daadwerkelijk is ingetrokken blijkt als volgt. Ik klik met de rechter muistoets op de malware file "1.dat" (na mijn virusscanner te hebben uitgezet en 1.dat uit de versleutelde zip file heb gehaald haal waarin ik deze bewaar), kies Properties (Eigenschappen) en open het tabblad Digital Signatures, zie linksboven in https://imgur.com/a/Vx8WT.
Daarna kan ik "Media Lid" selecteren en middels "View Certificate" de drie verschillende tabbladen van zo'n certificaat bekijken (zie het plaatje).
ECHTER, als ik dat certificaat exporteer naar een bestand (dat ik "Media Lid.cer" heb genoemd), in ik dubbel-klik daarop om dat certificaat te inspecteren, dan blijk UIT NIETS dat vdit certificaat is ingetrokken! Zie https://imgur.com/a/rMHPE.
Conclusie: de certificate viewer in Windows checkt uitsluitend op revocation van een code signing certificaat in de context van een gesigneerd bestand!
De reden hiervoor is vermoedelijk dat Authenticode niet kijkt naar de intrek- en/of verloopdatum van een code signing certificaat; wat telt is de timestamp (de datum en tijd) van ondertekenen. Die timestamp moet wel door een betrouwbare organisatie zijn aangeleverd (en zelf ook weer digitaal zijn ondertekend). Hierdoor kan zo'n code signing certificaat gewoon nog geldig zijn nadat de vervaldatum van het certificaat is gepasseerd. Indien een code signing certificaat is ingetrokken (revoked), is dat certificaat geldig vanaf het moment van uitgeven tot het moment van revocation!
Zonder een signing timestamp weet Windows dus niet of een code signing certificaat geldig is of niet.
Behoorlijk verwarrend wat mij betreft...
P.S. voordat iemand denkt dat ik hierdoor dacht dat de Thawte CRL niet werkte: ik heb wel degelijk steeds getest met "1.dat", zie https://imgur.com/a/UUxVP waar ik in https://www.security.nl/posting/526658/Falen+van+AV+industrie#posting527475 naar verwijs. Ik wist toen al dat de losse certifcate viewer niet deed wat ik verwachtte, ik had er toen alleen nog geen verklaring voor :-)
--------------------------------------------
Aanvulling 14:02 OOPS door mijn eigen verklaring hierboven snap ik nu ook waarom de revocation eind vorige week niet werkte (suf suf suf). Het certificaat was door Thawte ingetrokken per 10 augustus 2017, 00:00:00 en dat is na het zetten van de digitale handtekening onder de malware file "1.dat"!
Als je nu http://tl.symcb.com/tl.crl downloadt staat daarin dat het certificaat is ingetrokken per 27 juli 2017, 02:00:00" in dat is voordat de malware werd ondertekend.
Zie https://imgur.com/a/hbYpr voor de verschillen tussen de beide CRL files (links oud, rechts nieuw).
Het is dus heel belangrijk dat een code signing certificaat wordt ingetrokken net voor het eerst bekende misbruik daarvan, en niet later!
Uiteraard werkt dat zo, en dat is maar goed ook. Stel je voor dat bedrijf X een geldig certificaat heeft en daarmee
op grote schaal software released en dan valt de key van dat certificaat in verkeerde handen en wordt ingetrokken.
Als op dat moment al die software die er al was ineens niet meer zou werken zou het grote problemen kunnen geven.
(als dit bijvoorbeeld Windows was)
Probleem met een revocation date is natuurlijk: hoe voorkom je dat alsnog software wordt gesigneerd met een
fake timestamp wat voor de revocation date ligt.
op grote schaal software released en dan valt de key van dat certificaat in verkeerde handen en wordt ingetrokken.
Als op dat moment al die software die er al was ineens niet meer zou werken zou het grote problemen kunnen geven.
(als dit bijvoorbeeld Windows was)
Probleem met een revocation date is natuurlijk: hoe voorkom je dat alsnog software wordt gesigneerd met een
fake timestamp wat voor de revocation date ligt.
15-08-2017, 15:30 door
Bitwiper
Door Anoniem: Probleem met een revocation date is natuurlijk: hoe voorkom je dat alsnog software wordt gesigneerd met een fake timestamp wat voor de revocation date ligt.
Ik hoop dat alle erkende timestamping services (middels hun timestamp signing certificate) niet zodanig om te kopen zijn (en/of hun klok extern te beïnvloeden blijkt) dat zij timestamps in het verleden zetten.Als er 1 of meer partijen tussen zitten die dat wel doen, is dit hele model waardeloos.
Daarom moeten er toegevoegde checks komen. Certificeringsstatus -
en vooral checks op de implicatie/configuratie van een en ander.
De hele ontwikkeling rond de zogenaamde gratis pret-certificaatjes is in dit licht bezien ook een zorgelijke ontwikkeling,
net zoals https everywhere ook niet echt voor "everyone" is weggelegd of nodig is.
Mijn idee is dat het verdienmodel op de Infrastructuur zich niet zo graag op de commerciële vingertjes laat kijken
en de data-jassers dus graag non-public en in de cloud gaan.
Of dat voor alle Internetgebruikers een veilige ontwikkeling is, valt te betwijfelen.
Voor de datasjacheraars en ook voor de cybercriminelen is het overigens vaak zeer lucratief (data = het nieuwe goud).
Zo de waard is vertrouwt hij vaak zijn gasten. In het geval van SRI hashes (same origin regel),
zie je vaak kwetsbare sites na een hack keurig van de benodigde SRI hashes zijn voorzien
(door de cybercriminelen - het beveiligd misbruik model noem ik dat).
Zo gaat het hier ook. Er zijn kwetsbaarheden en hier maakt men misbruik van
en daarna stelt men het "alleenvertoningsrecht" veilig (zullen we maar zeggen).
En cybercriminelen hebben overal hun mannetjes/vrouwtjes zitten, dus ook bij CA instanties.
Uit de Google kritiek op Symantec CA (en onderdanen) model blijkt dat het systeem lekken vertoonde en nog vertoont.
Lees: https://groups.google.com/a/chromium.org/forum/?_escaped_fragment_=msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ#!msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ
alsmede: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ
Dank zij de draad en postings hier van Bitwiper, ben ik weer op een heleboel zaken
rond het herkennen van onbetrouwbare certificaten of certificeringsmisbruik beter gaan letten
en me gaan inlezen in de materie.
Nog veel dank, Bitwiper, dat je de beveiligingsgemeenschap hiervoor de ogen opent.;)
Ik check nu ook wel hier als bij dit voorbeeld: https://caatest.co.uk/vendercartoabom.com.br
waar we geen geldige hostnaam konden vinden - hostname komt niet overeen met het certificaat op deze PHISHING site.
Certificaat. niet juist geïnstalleerd bij Hostgator Wildcard - Comodo. (certificaatmisbruik wordt vaak gebruikt voor het faciliteren van "carding" (creditkaart criminaliteit). Dit mag niet te veel aandacht krijgen, want dat is slecht voor de economie en drijft de prijzen en het risico op voor webwinkels, etc.
Hoe genereert men CAA records: https://sslmate.com/labs/caa/
Testing: https://www.ssllabs.com/ssltest/ vergelijk deze gegevens met de resultaten van: cryptoreport.websecurity.symantec.com/checker/
en op
https://observatory.mozilla.org/
en
http://www.dnsinspect.com/
We zien nu hoe kwetsbaar het intrekken van een certificaat zijn kan.
Hoe de methode kwetsbaar is v/door o.m. sociale manipulatie (social engineering)
en de web-economie (security through obscurity).
Mooi klaar is de beveiligingswereld hiermee, waarvan akte.
luntrus
en vooral checks op de implicatie/configuratie van een en ander.
De hele ontwikkeling rond de zogenaamde gratis pret-certificaatjes is in dit licht bezien ook een zorgelijke ontwikkeling,
net zoals https everywhere ook niet echt voor "everyone" is weggelegd of nodig is.
Mijn idee is dat het verdienmodel op de Infrastructuur zich niet zo graag op de commerciële vingertjes laat kijken
en de data-jassers dus graag non-public en in de cloud gaan.
Of dat voor alle Internetgebruikers een veilige ontwikkeling is, valt te betwijfelen.
Voor de datasjacheraars en ook voor de cybercriminelen is het overigens vaak zeer lucratief (data = het nieuwe goud).
Zo de waard is vertrouwt hij vaak zijn gasten. In het geval van SRI hashes (same origin regel),
zie je vaak kwetsbare sites na een hack keurig van de benodigde SRI hashes zijn voorzien
(door de cybercriminelen - het beveiligd misbruik model noem ik dat).
Zo gaat het hier ook. Er zijn kwetsbaarheden en hier maakt men misbruik van
en daarna stelt men het "alleenvertoningsrecht" veilig (zullen we maar zeggen).
En cybercriminelen hebben overal hun mannetjes/vrouwtjes zitten, dus ook bij CA instanties.
Uit de Google kritiek op Symantec CA (en onderdanen) model blijkt dat het systeem lekken vertoonde en nog vertoont.
Lees: https://groups.google.com/a/chromium.org/forum/?_escaped_fragment_=msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ#!msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ
alsmede: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ
Dank zij de draad en postings hier van Bitwiper, ben ik weer op een heleboel zaken
rond het herkennen van onbetrouwbare certificaten of certificeringsmisbruik beter gaan letten
en me gaan inlezen in de materie.
Nog veel dank, Bitwiper, dat je de beveiligingsgemeenschap hiervoor de ogen opent.;)
Ik check nu ook wel hier als bij dit voorbeeld: https://caatest.co.uk/vendercartoabom.com.br
waar we geen geldige hostnaam konden vinden - hostname komt niet overeen met het certificaat op deze PHISHING site.
Certificaat. niet juist geïnstalleerd bij Hostgator Wildcard - Comodo. (certificaatmisbruik wordt vaak gebruikt voor het faciliteren van "carding" (creditkaart criminaliteit). Dit mag niet te veel aandacht krijgen, want dat is slecht voor de economie en drijft de prijzen en het risico op voor webwinkels, etc.
Hoe genereert men CAA records: https://sslmate.com/labs/caa/
Testing: https://www.ssllabs.com/ssltest/ vergelijk deze gegevens met de resultaten van: cryptoreport.websecurity.symantec.com/checker/
en op
https://observatory.mozilla.org/
en
http://www.dnsinspect.com/
We zien nu hoe kwetsbaar het intrekken van een certificaat zijn kan.
Hoe de methode kwetsbaar is v/door o.m. sociale manipulatie (social engineering)
en de web-economie (security through obscurity).
Mooi klaar is de beveiligingswereld hiermee, waarvan akte.
luntrus
Nu is xs4all.nl wel een mooi voorbeeld met name wat betreft de nameserver info proliferatie voor:
"PowerDNS Authoritative Server 4.0.4 (built Jun 22 2017 20:42:20 by root@87b8ee920749)",
die een probleem geeft met het afhandelen van faulty bind backend slave zones van eerdere versies(3.4)
en wat in dit verband een zeker een probleem is bugs vertoont bij het verwerken van timestamps
en daar waarschijnlijk kwetsbaar is voor misbruik bij pdns (PowerDNS)
als je de authorisatieserver benadert vanaf een oudere versie van deszelvers.
xs4all heeft geen CAA geïnstalleerd!!!
C-grade status hier en aanbevelingen: . https://observatory.mozilla.org/analyze.html?host=www.xs4all.nl
Ze zijn al omhooggeklommen van D via C naar C+.
A+ https://www.ssllabs.com/ssltest/analyze?d=www.xs4all.nl
E-status behoeft verbetering: https://securityheaders.io/?followRedirects=on&hide=on&q=www.xs4all.nl
Geen pre-loading: Domain is a subdomain, and can't be preloaded.
HSTS header missing the "includeSubDomains" attribute.
HSTS header missing the "preload" attribute.
Complete Results: https://hstspreload.org/?domain=www.xs4all.nl
luntrus
"PowerDNS Authoritative Server 4.0.4 (built Jun 22 2017 20:42:20 by root@87b8ee920749)",
die een probleem geeft met het afhandelen van faulty bind backend slave zones van eerdere versies(3.4)
en wat in dit verband een zeker een probleem is bugs vertoont bij het verwerken van timestamps
en daar waarschijnlijk kwetsbaar is voor misbruik bij pdns (PowerDNS)
als je de authorisatieserver benadert vanaf een oudere versie van deszelvers.
xs4all heeft geen CAA geïnstalleerd!!!
C-grade status hier en aanbevelingen: . https://observatory.mozilla.org/analyze.html?host=www.xs4all.nl
Ze zijn al omhooggeklommen van D via C naar C+.
A+ https://www.ssllabs.com/ssltest/analyze?d=www.xs4all.nl
E-status behoeft verbetering: https://securityheaders.io/?followRedirects=on&hide=on&q=www.xs4all.nl
Geen pre-loading: Domain is a subdomain, and can't be preloaded.
HSTS header missing the "includeSubDomains" attribute.
HSTS header missing the "preload" attribute.
Complete Results: https://hstspreload.org/?domain=www.xs4all.nl
luntrus
Nog iets. Alles is ook nog eens platformafhankelijk.
Dit bericht kreeg ik in de Browzar broser tijdens het downloaden van www.ad.nl website.
Browzar is een browser endpoint gebaseerd op Edge en laadt beperkt..
en verwijdert bij sluiten: geschiedenis, cookies, tijdelijke internet files, etc.
Java en Flash heb ik niet geïnstalleerd om duidelijke redenen.
Beveiligingswaarschuwing
Er is geen informatie over het intrekken van het beveiligingscertificaat voor deze website beschikbaar.
Wilt u doorgaan?
Cerrtificaat weergeven Certficaat informatie
Het garanderen van de identiteit van een externe computer.
verleend aan *.hotjar.com
verleend door: Gandi Standard SSL CA2
Certificaat installeren -> cps.usertrust.com via cloudfront.net...
Zie: https://certificatedetails.com/5379bf5aaa2b4acf5480e1d89bc09df2b20366cb/5e4dc3b9438ab3b8597cba6a19850e3/gandistandardsslca2
en
https://certificate.revocationcheck.com/hotjar.com
Lees op StackExchange Serverfault hierover dit:
https://serverfault.com/questions/656558/the-certificate-is-not-trusted-because-the-issuer-certificate-is-unknown-error
luntrus
Dit bericht kreeg ik in de Browzar broser tijdens het downloaden van www.ad.nl website.
Browzar is een browser endpoint gebaseerd op Edge en laadt beperkt..
en verwijdert bij sluiten: geschiedenis, cookies, tijdelijke internet files, etc.
Java en Flash heb ik niet geïnstalleerd om duidelijke redenen.
Beveiligingswaarschuwing
Er is geen informatie over het intrekken van het beveiligingscertificaat voor deze website beschikbaar.
Wilt u doorgaan?
Cerrtificaat weergeven Certficaat informatie
Het garanderen van de identiteit van een externe computer.
verleend aan *.hotjar.com
verleend door: Gandi Standard SSL CA2
Certificaat installeren -> cps.usertrust.com via cloudfront.net...
Zie: https://certificatedetails.com/5379bf5aaa2b4acf5480e1d89bc09df2b20366cb/5e4dc3b9438ab3b8597cba6a19850e3/gandistandardsslca2
en
https://certificate.revocationcheck.com/hotjar.com
Lees op StackExchange Serverfault hierover dit:
https://serverfault.com/questions/656558/the-certificate-is-not-trusted-because-the-issuer-certificate-is-unknown-error
luntrus
Een oplossing waar men op IPs en certificering kan zoeken is Threatminer.
Bij voorbeeld: https://www.threatminer.org/ssl.php?q=09d78e3a29527d3d058a49645e14f5101a7a8a16
Bij voorbeeld: https://www.threatminer.org/ssl.php?q=09d78e3a29527d3d058a49645e14f5101a7a8a16
Omdat het niet meer echt en eenduidig veilig te krijgen valt, wil men HTTP public key pinning laten vallen, ze hebben het kleed onder HPKP dus nu weggetrokken.
Achtergrond verhaal: https://www.theregister.co.uk/2017/08/25/hpkp_crypto_criticism/ (link auteur = John Leyden)
Vanwege de complexiteit en aanvallen als deze: https://scotthelme.co.uk/using-security-features-to-do-bad-things/
Trust chains dienen ongebroken te zijn, nooit mogen bij het uitgeven van certificaten fouten zijn gemaakt, beter om deze dan een oplossing te zoeken via https://certificatechain.io/ en dan de code nog eens goed tegen het licht te houden en te checken op de juistheid.. Cerificaten horen in je DNSSEC authenticated DNS records te staan.
Misschien moeten we CAs helemaal uit browsers weren, tenminste slotjes oranje kleuren of zoiets dergelijks,
tot DANE zijn introductie in de browser heeft gedaan (Chrome & firefox etc.). Banken zijn meestal nog niet zo ver met het overgaan op DANE coderen in de browser.
Hoog tijd voor de overstap naar DNSSEC, dit als een samenvatting van comentaar op het artikel van John Leyden op de REG.
Achtergrond verhaal: https://www.theregister.co.uk/2017/08/25/hpkp_crypto_criticism/ (link auteur = John Leyden)
Vanwege de complexiteit en aanvallen als deze: https://scotthelme.co.uk/using-security-features-to-do-bad-things/
Trust chains dienen ongebroken te zijn, nooit mogen bij het uitgeven van certificaten fouten zijn gemaakt, beter om deze dan een oplossing te zoeken via https://certificatechain.io/ en dan de code nog eens goed tegen het licht te houden en te checken op de juistheid.. Cerificaten horen in je DNSSEC authenticated DNS records te staan.
Misschien moeten we CAs helemaal uit browsers weren, tenminste slotjes oranje kleuren of zoiets dergelijks,
tot DANE zijn introductie in de browser heeft gedaan (Chrome & firefox etc.). Banken zijn meestal nog niet zo ver met het overgaan op DANE coderen in de browser.
Hoog tijd voor de overstap naar DNSSEC, dit als een samenvatting van comentaar op het artikel van John Leyden op de REG.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
