Hoe wil je eigenlijk een file eigenschap veranderen met een protocol tussen website en gebruiker, want dat is https.

Niet onder iOS en iPadOS. En dat is niet onmogelijk onder die besturingssystemen, want Google Chrome ondersteunt dit wel.

Als je "https only" goed hebt ingesteld moet jouw browser een waarschuwing geven als je:

    http://http.badssl.com

opent. Als je, zonder te zijn gewaarschuwd, een rood scherm met witte tekst "http.badssl.com" ziet, is jouw browser kwetsbaar voor AitM aanvallen (Attacker in the Middle, ook bekend als MitM met Man voor de eerste M).

Helaas is de naam van de browser-instelling m.i. "https only" een slechte keuze: het had moeten luiden "http warning" (want dat is het; het betekent niet dat je geen http meer kunt gebruiken, maar slechts dat je dat moet bevestigen - een prima waarschuwing dus).

En niet alleen is de naam ongelukkig, ik vind het absurd dat dit niet standaard aan staat in alle webbrowsers (helemaal stom is dat je het in sommige browsers niet eens aan kunt zetten).

LET OP: als je, zonder https only, bijvoorbeeld:

    almere.nl

(gevolgd door Enter) intikt in de adresbalk van jouw browser, loop je ook risico op een AitM-aanval - zelfs als jouw browser van het moderne type is dat éérst https probeert! Een AitM kan dat https-verzoek naar almere.nl namelijk eenvoudig blokkeren.

Zodra jouw browser daarna stilletjes http://almere.nl probeert, kan de aanvaller zich voordoen als almere.nl.

En, desgewenst, zodra die website is "geopend", jouw browser doorsturen naar een phishingsite met een andere domeinnaam en met een geldig https servercertificaat, denk aan iets als https://almere-gemeente,com (met een punt i.p.v. een komma - die ik ertussen zette om per ongelukt openen te voorkómen - mocht die site nu of ooit bestaan).

Nb. dit kan zó snel gaan dat je dat niet hoeft te zien! Bovendien komt het ook voor dat legitieme websites jouw browser doorsturen. Echter, zolang elke verbinding via https tot stand komt, kan een AitM daar -normaal gesproken (*)- niet tussenkomen.

(*) Behoudens zeldzame gevallen zoals indien een certificaat onterecht is afgegeven, een private key van een webserver is gekopiejat of als je een fout (of gecompromitteerd) rootcertificaat hebt geïnstalleerd.

Helaas vind je op veel websites nog steeds links die met http beginnen, en ook in QR-codes zie ik dat vaak - terwijl de betreffende website allang https ondersteunt. Als je https only hebt aangezet, zal de browser eerst https proberen en je waarschuwen als dat niet lukt.

Met https only ingeschakeld word je ervoor gewaarschuwd dat een website geen https ondersteunt, maar ook als de verbinding (door een AitM of t.g.v. een configuratiefout) "gedowngraded' wordt naar http; dat hoort bij geen enkele fatsoenlijke website nog te gebeuren (werk.nl ondersteunt sinds juli vorig jaar ook https: https://security.nl/posting/803597).

Vooral als je op een publiek WiFi-netwerk zit: tik altijd https:// vóór elke domeinnaam in de adresbalk van jouw browser.

Overigens ben je niet alleen kwetsbaar op publiek WiFi: als je, met jouw computer, tablet of smartphone via een vertrouwd netwerk een internetverbinding hebt (vooral als je geen DoH, DNS over Https, gebruikt), en je almere.nl + Enter hebt ingevoerd in de adresbalk van jouw browser, kan een aanvaller het DNS-antwoord vervalsen, en jouw browser zó naar een andere website sturen - die https://almere.nl blokkeert, maar http://almere.nl niet (en, desgewenst, daarna jouw browser doorstuurt).

Ten slotte: https only aanzetten is veiliger dan vertrouwen op HSTS (info: https://security.nl/posting/802243), want dat werkt lang niet altijd, en de kans dat je https:// vergeet in te tikken, een stomme QR-code scant of of een http-link klikt, is aanzienlijk.

Aanvulling 18:33: in https://www.security.nl/posting/840518 ging ik hier eerder op in, en beschreef een "hack" hoe je https only in Microsoft Edge onder Windows kunt aanzetten.

Wat ik mis zijn legitieme https sites die een eigen CA/root en IM-cert hebben, die krijgen (vaak onterecht) een waarschuwing omdat deze niet gekoppeld zijn aan de standaard CA's. Alsof deze ineens onveilig zijn... Er zijn proportioneel veel meer onveilige sites met een cert van de standaard CA's dan degene met een eigen CA/root.

Een https servercertificaat heeft *niets* te maken met hoe veilig een website is.

In https://www.virustotal.com/gui/domain/rm-reschedule-delivery.com/summary zie je onderin de domeinnaam van een website die (volgens 25 van 93 scanners) onveilig is, terwijl je in https://www.virustotal.com/gui/domain/rm-reschedule-delivery.com/details het laatste certificaat van die website kunt zien.

Bij de al jaren gangbare Diffie-Hellman key agreement (t.b.v. forward security) heeft een https servercertificaat namelijk slechts één doel: authenticatie van de website (bewijs van identiteit, op z'n minst de domeinnaam).

Bij TLS v1.3 is de verbinding zelfs al versleuteld vóórdat de server haar certificaat naar de browser stuurt - waardoor dit uitsluitend door een actieve AitM kan worden ingezien.

Maar als er een AitM "tussen zit", zal de browser een certificaatfoutmelding tonen (want de AitM beschikt -normaal gesproken- niet over de private key van de echte server, waarmee die server de gezamenlijke DHE-parameters digitaal ondertekent. Om deze vervolgens, inclusief handtekening, naar de browser te sturen; een AitM kan die DHE parameters -normaal gesproken- niet hergebruiken voor diens verbinding richting de browser).

Dus is een https servercertificaat, dat niet door een vertrouwde derde partij is afgegeven, volstrekt zinloos. Browsers zouden dan net zo goed https gebaseerd op certificaatloze TLS kunnen ondersteunen; dat is net zo (on)veilig en minder werk voor serverbeheerders dan knutselen met self-signed certificaten.

Bewijs graag (en vertel erbij of je "onveilige websites", "onveilige verbindingen met de juist websites" of "veilige verbindingen met nepwebsites" bedoelt).

Dit noem ik een respectloze reactie op de techniek, wijze van CA/IM distributie en beheer door diegene die echt wel weten hoe dit werkt maar niet gekoppeld willen zijn aan het root/CA risico/monopoly. Als ander voorbeeld het KMS systeem van AWS, als je hier niet zelf het eigen beheer over doet doe je ook mee aan het kms risico/monopoly.

Ja het is allemaal erg makkelijk (gemaakt) om snel certs uit te rollen (op welk platform dan ook, CA of AWS) maar je onderschat het risico wat we allemaal hiermee lopen.

Ga eens wat gedegen onderzoek doen naar de risico's van centrale en eigen CA's, of ben je deze al weer vergeten? https://en.wikipedia.org/wiki/DigiNotar
Voordat je de nogal domme uitspraak nogmaals doet "dan knutselen met self-signed certificaten".

Gelukkig weet de anonieme "expert" wél hoe het werkt (bizar de hoeveelheid fake news, niet onderbouwd met feiten, op deze site).

Dit is/was geen fake news, je wil het niet begrijpen, wellicht een wat ander voorbeeld,

Stel in NL doet iedereen de auto rijlessen en rij examen via de ANWB, dat zal dan z'n 95% zijn, de overige 5% gaan we classificeren als knutselende rijles instructeurs, dus is een rijles & rijbewijs, dat niet door een vertrouwde derde partij is afgegeven, volstrekt zinloos. JIJ gaat hier helemaal voorbij dat dit gemeenschap aannames zijn maar met jou uitspraak maak je er een feit van.

JIJ stelt dat de root/CA's een vertrouwde derde partij is en JIJ stelt daarmee automatisch dat al het andere volstrekt zinloos en onbetrouwbaar zijn, ea. schapen gedrag achter de meute aanlopen.

Nee, dat deed ik niet. Ik schreef:
Voorwaarde is altijd dat de gebruiker van de browser de certificaatuitgever (effectief de keten van certificaatuitgevers of, als de gebruiker de de gebruikte keten niet checkt, zelfs alle door de browser vertrouwde ketens van certificaatuitgevers) moet vertrouwen.

En wel op die manier dat, als op een webserver een website "draait" zoals (+):


die als twee druppels water op elkaar lijken, de bezoeker in alle 18 gevallen behoorlijk zeker weet dat diens browser daadwerkelijk verbinding heeft met de webserver met resp. de achter 1) t/m 18) genoemde domeinnamen (volgend op "https://").

(Daar heeft die gebruiker natuurlijk helemaal niets aan als zij of hij niet weet welke domeinnaam precies verwijst naar een IP-adres van een échte authenticatieserver voor medewerkers van T-Mobile - maar dat was niet het onderwerp dat door jou werd aangekaart).

Oftewel, als de keten van certificaatuitgevers voor 100% betrouwbaar is, is de kans zeer klein dat jouw browser een foutmeldingsloze https-verbinding krijgt met een andere server (een AitM of een ander eindpunt) dan waar resp. 1) t/m 18) naar verwijzen.

Naarmate je de keten van certificaatuitgevers minder dan 100% vertrouwt, neemt jouw risico op een AitM (of ander eindpunt) toe als je één of meer URL's uit de reeks van 1) t/m 18) bezoekt.

(+) Om per ongeluk openen te voorkómen heb ik steeds https door hxxps vervangen (aanleiding voor deze lijst was https://www.virustotal.com/gui/domain/okta-tmobile.com/summary die recentelijk door VT gescand is, maar veel van de andere foute domeinnamen zijn ook geregistreerd; een paar ongevaarlijke niet). Enorm veel andere variaties zijn ook mogelijk, zoals het toevoegen van auth, login, signon, sso en/of secure. Of door het gebruiken van octa i.p.v. okta, tmobiIe i.p.v. tmobile, 0 i.p.v. o of met een Unicode t' met een accentje (een letter die ik op dit forum niet goed kan laten zien, maar wel in https://www.virustotal.com/gui/url/1f6f1eb412b82aaaa8583a72ede2bdb02fa604d60b4f9976fd6ff7a531b09376 en in https://www.charset.org/punycode?encoded=xn--atoscou24-w4b1m.de&decode=Punycode+to+normal+text).

En eerder schreef ik:

Ik stel dus nergens dat, welke Certificate Authority dan ook, per definitie betrouwbaar zou zijn.

Niet al het andere.

Als ik mij niet vergis gebruikt de Amerikaanse defensie voor een deel van haar computersystemen een geheel eigen PKI (Public Key Infrastructure), waarbij ik aanneem dat de certificaatuitgifte daarbij aan zeer strenge beveiligingseisen voldoet.

Als burger/consument zijn de mogelijkheden beperkt en/of risicovol. Zo kun je (meestal met veel moeite en vaak slechte documentatie) in besturingssystemen en/of met webrowsers meegeleverde rootcertificaten verwijderen of "distrusten". Vaak is het eenvoudiger om zelf rootcertificaten toe te voegen, maar dan moet je erop kunnen vertrouwen dat de bezitter van de private key daarvan is wie zij/hij zegt te zijn, niet onterecht intermediate- en leaf-certificaten uitgeeft en de private keys (horend bij root- en intermediate certs) nooit lekt.

M.b.t. elk self-signed certificaat (incl. rootcertificaten) geldt: tenzij je via een ander (wel betrouwbaar) kanaal bijv. een kopie of een cryptografisch veilige hash van dat certificaat hebt gekregen en hebt vergeleken met (de hash van) het via https verkregen certificaat en dat identiek blijkt te zijn, zegt een self-signed certificaat (met bijpassende private key) precies niets over de betrouwbaarheid daarvan - temeer daar je, fundamenteel, verbindingen prima kunt versleutelen zonder daarbij een certificaat te gebruiken.

Je hebt trouwens, na mijn eerdere vraag, nog geen enkel bewijs aangeleverd:

"Bewijs graag (en vertel erbij of je "onveilige websites", "onveilige verbindingen met de juist websites" of "veilige verbindingen met nepwebsites" bedoelt)."

Dat kan je zelf ook uitzoeken en enigszins bewijzen met AI, afwijkingen daargelaten klopt dit aardig,

"can you approximately calculate the amount of malicious websites using https and using common certificate authorities versus the amount of malicious websites using https with self signed certificates"

Note: the question should be amended with the use of self created root/CA, managed IM'rs but it would not significantly change the result.

ChatGPT:

To approximate the number of malicious websites using HTTPS with common certificate authorities versus those using self-signed certificates, we can consider some general observations and data points from cybersecurity reports and research. Here’s a step-by-step approach to making this estimation:

### 1. Understand HTTPS Adoption
- **HTTPS with Common CAs**: Most websites, including malicious ones, use HTTPS certificates issued by common certificate authorities (CAs) like Let's Encrypt, DigiCert, Comodo, etc., because they are trusted by browsers and users are less likely to see warnings.
- **HTTPS with Self-Signed Certificates**: Self-signed certificates are less commonly used because they trigger browser warnings, which can deter visitors, including potential victims.

### 2. Review Existing Research and Data
- **Reports on HTTPS Adoption by Malicious Sites**: There are various reports and studies on the use of HTTPS by malicious websites. For example, reports by cybersecurity firms like Symantec, PhishLabs, or Anti-Phishing Working Group (APWG) often include statistics on this.
- **Certificate Transparency Logs**: These logs can be used to get an idea of the distribution of certificates.

### 3. Estimation Based on Available Data
Based on general cybersecurity insights, here is a simplified estimation:

- **Percentage of Malicious Sites Using HTTPS**: Recent trends indicate that a significant portion of malicious sites use HTTPS. For example, some reports suggest that over 70% of phishing sites use HTTPS.
- **Distribution Between Common CAs and Self-Signed Certificates**: Among HTTPS-using malicious sites, the vast majority use certificates from common CAs due to their trusted status.

### Example Calculation
1. **Total Malicious Websites**: Assume there are 1,000,000 malicious websites.
2. **Malicious Websites Using HTTPS**: If 70% use HTTPS, that's 700,000 websites.
3. **Distribution Between Common CAs and Self-Signed Certificates**:
- **Common CAs**: Assume 95% use certificates from common CAs (trusted).
- **Self-Signed**: Assume 5% use self-signed certificates (untrusted).

#### Calculations:
- Malicious websites using HTTPS with common CAs: \(700,000 \times 0.95 = 665,000\)
- Malicious websites using HTTPS with self-signed certificates: \(700,000 \times 0.05 = 35,000\)

### Summary
- **Malicious websites using HTTPS with common CAs**: Approximately 665,000
- **Malicious websites using HTTPS with self-signed certificates**: Approximately 35,000

### Conclusion
This estimation suggests that the majority of malicious websites that use HTTPS are utilizing certificates issued by common, trusted certificate authorities, while a smaller proportion relies on self-signed certificates. This is consistent with the general trend towards adopting trusted HTTPS certificates to avoid browser warnings and increase the chances of successfully deceiving users.

Op 11-06-2024, 18:41 schreef Anoniem in https://security.nl/abuse/845395 onder meer (nadruk toegevoegd door mij):
Los van het antwoord van Artificial Incompetence hierboven op een andere vraag, zou Anoniem wel eens gelijk kunnen hebben: je moet als cybercrimineel wel héél stom zijn om jouw phishing-website niet van een gratis certificaat te voorzien (*), want gewaarschuwde mensen trappen minder snel in phishing.

Als je een winkel of een bankfiliaal binnenloopt, of als je jouw bankpas in een geldautomaat of betaalterminal stopt en de bijbehorende pincode invoert, is het risico (in elk geval in Nederland) dat deze niet van de kennelijke eigenaar of bank is, erg klein.

Naarmate een klant met grotere zekerheid weet wie de verantwoordelijke verkoper is en waar deze gevestigd is, des te groter de pakkans is als de verkoper de boel belazert.

Als iemand, die jij niet kent, jou op straat voor 200 Euro een "Rolex" of een z.g.a.n. fatbike aanbiedt, zou jij die kopen?

Los van de sukkels die daar intrappen: het offline systeem (weten met wie je zaken doet) werkt prima in de praktijk en voorkómt daarmee enorm veel criminaliteit (zonder dat velen zich dat beseffen).

Uitgevers van https servercertificaten garanderen nooit de veiligheid van een website, noch de betrouwbaarheid van de eigenaar.

Wél kunnen uitgevers van https servercertificaten, met minder of meer moeite, vaststellen:

1) Wie de aanvrager is van een certificaat voor een gegeven domeinnaam, én

2) Dat die domeinnaam daadwerkelijk gekoppeld is aan een specifieke server.

Met één primair doel: dat niet élke bezoeker van een website zélf (kansloos natuurlijk) moet zien te achterhalen wie de verantwoordelijke achter een website is en waar deze gevestigd is (inclusief land, i.v.m. de kans op vervolging bij criminaliteit) - zodat die verantwoordelijk opgespoord en vervolgd kan worden indien deze de boel belazert.

Met als secundair doel dat veel minder mensen online worden belazerd.

Vanzelfsprekend onder de essentiële voorwaarden daarvoor dat a) certificaatuitgevers de boel niet belazeren en b) dat mensen, op basis van die certificaten, daadwerkelijk zien met wie zij zaken doen.

Helaas heeft met name Google stap 1) hierboven om zeep geholpen - terwijl die huichelaar wel wil dat marktpartijen veel geld uitgeven aan zinloze BIMI-certificaten (https://security.nl/posting/845483).

(*) Sterker, vermoedelijk om diens reputatie bij blocklist- en antivirus-makers op te krikken, verkrijgt de Russische hoster "Ddos guard" dagelijks probleemloos honderden Domain Validated Let's Encrypt certificaten voor niet-kwaadaardige "Lorem Ipsum"-achtige websites (die geen weldenkend mens gaat bezoeken) met semi-random subdomeinnamen, momenteel voorafgaand aan o.a. rupw[.]org, join[.]tg en melbet-link[.]com (zie bijv. https://crt.sh/?Identity=prokatavto32.ru&exclude=expired&deduplicate=Y (geduld is nodig, het zijn er absurd veel) en/of https://www.virustotal.com/gui/ip-address/185.178.208.156/relations).

Dit certificaten-systeem is doodziek.
Het is totaal niet in het belang van internettende mensen maar uitsluitend van big tech en hun aandeelhouders.

Een voorbeeld van alleen al vandaag door VT gescande websites (allen 0/93, en VT scant niet zomaar elke nieuwe domeinnaam) uit de laatstgenoemde URL (ik heb elke punt vervangen door '·' en ik heb 4 domeinnamen, eindigend op kinogo·baby, verwijderd omdat die nieuw en mogelijk kwaadaardig zijn):