Door Anoniem: Door Anoniem: Door Anoniem: Zeker in een tijd dat browsers voor RFC1918 addressen al RC4 verbannen.
volgens mij haal je hier wat zaken door elkaar.
Nee, wat ik bedoel te zeggen is dat 'echte' certificaten niet op RFC1918 hoeven te draaien, dit is immers 'intern',
TLS server certificaten, met de bijbehorende geauthenticeerde verbindingen, hebben in principe *NIETS* te maken met IP-adressen, dus ook niet met adressen uit de "private range" reeksen gedefinieerd in RFC1918.
Zelfs als jouw webserver bereikbaar is via IPX, AppleTalk of een RS-232 lijntje, kun je er een certificaat opzetten - de enige voorwaarden daarvoor zijn:
1) Voor alle (TCP/IP pratende) webbrowsers die ermee moeten kunnen verbinden, moet minstens één van de domeinnamen in het certificaat resolven naar een willekeurig IP-adres (en de gebruiker moet zo'n domeinnaam gebruiken in de URL);
2) Routering moet ervoor zorgen dat pakketjes, die door de webbrowser naar dat IP-adres worden gestuurd, uitkomen op jouw server en vice versa.
Voor certificaten
uitgegeven door CSP's voor publiek Internet geldt de aanvullende eis dat elke "domeinnaam" in het certificaat (waar dat cert. voor geldt) uniek moet zijn (met wildcard certificaten als enige uitzondering op deze regel, een uitzondering die overigens niet bestaat bij EV certificaten). Ik schreef "domeinnaam" tussen aanhalingstekens, want dit mag ook een IP-adres zijn - mits uniek aan het publieke internet (daardoor heeft bijvoorbeeld
https://1.1.1.1/ een geldig certificaat).
Een RFC1918 IP-adres is niet uniek en hoort bovendien niet te routeren op het publieke internet. Alleen al vanwege dat eerste aspect kun je daar geen "commercieel" certificaat meer voor krijgen - en je kunt er
zeker geen DV (Domain Validated) certificaat voor krijgen omdat de authenticiteitscheck van DV vereist dat er een route bestaat tussen de DV CSP en het IP-adres van jouw server (en terug natuurlijk).
Door Anoniem: maar ook daar wordt RC4 geblokkeerd. En dat is onzettend <ruk> als je firewalls eerst moet updaten voordat je erbij kunt. Checkpoint 1900 series bijvoorbeeld met <= R77 of Ubiquiti gateways en controllers.
Heel sneu voor je dat je nog met dergelijke museumstukken moet werken, maar de relatie met certificaten ontgaat me. Tuig een VM op met WFW 3.11 + TCP/IP stack + Netscape 1.0: probleem opgelost.
Door Anoniem: TLS-SNI werkt niet meer, dat is uitgezet na een hack:
" Let's Encrypt has disabled TLS-SNI-01 validation after the discovery of an attack able to hijack certificates ."
Dat is geen hack, maar by design bij alle DV speelgoedcertificaten: als jij configuratie-toegang hebt tot een webserver op een willekeurig IP-adres, kun je een DV certificaat krijgen
voor elke gewenste domeinnaam die -op dat moment- (bijv. via een door jou uitgevoerde DNS poisoning attack, onrechtmatige toegang tot DNS records of evt. via een BGP hijack) resolvt
en routeert naar dat IP-adres.
Voorbeeld: stel je bent crimineel en wilt malware installeren op PC's van mensen die via een publieke WiFi hotspot internetten. Je weet dat ze regelmatig software downloaden van https://www.example.com/ met IP-adres 93.184.216.34. Stel op datzelfde IP-adres zitten meerdere andere websites, dan hoef je maar 1 van die websites te hacken (of de eigenaar van een van die websites met een smoes om te kopen) om een DV certificaat voor www.example.com te verkrijgen, dat je vervolgens bij een MitM aanval kunt inzetten.
Door Anoniem: Het probleem is dat ik GEEN shit op poort 80 wil hebben draaien vanwege scanners die dan verder gaan kijken.
Ah now we're getting somewhere. Wellicht is bekend vanaf welke IP-adressen Let's Encrypt jouw server belt en kun je een firewall rule maken die poort 80 alleen voor die IP-adressen openzet?