Let's Encrypt geeft voor het eerst certificaat uit voor ip-adres
Certificaatautoriteit Let's Encrypt heeft voor het eerst een certificaat voor een ip-adres uitgegeven. Sinds de certificaatautoriteit tien jaar geleden startte kreeg het al verzoeken om deze mogelijkheid, maar de feature is nu pas toegevoegd en zal later dit jaar voor meer gebruikers beschikbaar komen. Let's Encrypt biedt gratis tls-certificaten aan die worden gebruikt voor het versleutelen van de verbinding tussen websites en bezoekers en maken het mogelijk om websites te identificeren.
Certificaten worden meestal voor domeinnamen uitgegeven. Dit heeft volgens Let's Encrypt verschillende redenen. Internetgebruikers kennen websites aan de hand van de domeinnaam, niet het ip-adres. Daarnaast kunnen ip-adressen van websites op elk moment veranderen. Een andere reden is dat het "eigenaarschap" van een ip-adres zwakker lijkt te zijn dan bij een domeinnaam het geval is, aldus de certificaatautoriteit.
Als laatste verwachten de meeste internetproviders niet dat eindgebruikers bewust, direct via een ip-adres verbinding maken. Wanneer een ip-adres door meerdere websites of apparaten wordt gedeeld zou het verbinden naar een ip-adres ook niet goed werken. Het heeft in dit scenario dan ook weinig zin een certificaat voor een ip-adres aan te vragen.
Volgens Let's Encrypt is een certificaat voor een domeinnaam dan ook de beste keuze voor de meeste gebruikers. Er zijn echter verschillende scenario's waarin een certificaat voor een ip-adres wel geschikt is, bijvoorbeeld voor het beveiligen van remote toegang tot apparaten in huis, het beveiligen van verbindingen binnen een cloudinfrastructuur, voor een standaardpagina door hostingproviders of een manier om een website te benaderen wanneer er geen domeinnaam is. De mogelijkheid om certificaten voor ip-adressen aan te vragen komt later dit jaar breed beschikbaar. De certificaten zullen voor slechts zes dagen geldig zijn en kunnen automatisch worden verlengd.
Lijkt me een strak plan.
Lijkt me een strak plan.
Misleid over wat!? TLS is alleen nog maar voor encryptie en zo word je tenminste veilig misleid als ik jouw gedachtengang volg.
Lijkt me een strak plan.
De idioot die een "server" in zo'n configuratie (dhcp ip en blijkbaar zelf geen controle over semi-statisch ip) dan toch een certificaat op IP laat aanvragen verdient ook alles wat er dan mis kan gaan .
Als je in een situatie zit waarin een bepaalde techniek voor jou niet geschikt is moet je die ook niet gebruiken.
Veel strakker plan - weten wanneer je iets niet moet doen. Het is niemand anders verantwoordelijkheid.
Lijkt me een strak plan.
De idioot die een "server" in zo'n configuratie (dhcp ip en blijkbaar zelf geen controle over semi-statisch ip) dan toch een certificaat op IP laat aanvragen verdient ook alles wat er dan mis kan gaan .
Als je in een situatie zit waarin een bepaalde techniek voor jou niet geschikt is moet je die ook niet gebruiken.
Veel strakker plan - weten wanneer je iets niet moet doen. Het is niemand anders verantwoordelijkheid.
Ach, ik ken een bedrijf dat ip tooling aanbiedt waarbij de techneut beweerde dat servers dynamische (dhcp) adressen moesten hebben. De tool was redundant uitgevoerd, en de redundante DNS servers zaten op 1 adres met tevens beheer op datzelfde adres. Zijn argument was dat een LAN iets anders is dan het internet. Drie maal raden wat er gebeurde toen een interne techneut per ongeluk datzelfde ip adres gebruikte voor iets anders... Bedrijf lag plat.
Sindsdien staat dat bedrijf bij mij op een blacklist vanwege gebrek aan kennis en begrip. Dus inderdaad, eens met de vorige poster dat die aanvrager verdient dat er van alles mis gaat.
[..]
Ach, ik ken een bedrijf dat ip tooling aanbiedt waarbij de techneut beweerde dat servers dynamische (dhcp) adressen moesten hebben. De tool was redundant uitgevoerd, en de redundante DNS servers zaten op 1 adres met tevens beheer op datzelfde adres. Zijn argument was dat een LAN iets anders is dan het internet. Drie maal raden wat er gebeurde toen een interne techneut per ongeluk datzelfde ip adres gebruikte voor iets anders... Bedrijf lag plat.
Ik snap het niet helemaal : grote storing wanneer een duplicatie IP voor een 'belangrijk' systeem aanwezig is : dat kan ik begrijpen .
Maar je lijkt te willen zeggen dat die tool die op dhcp-gebaseerde servers zat daar geen last van gehad had als de adressen statisch waren, ofzo ?
Ik moet zeggen dat met duplicate IPs - (als ik die mag aanwijzen) wel heel veel omgevingen, ook redundante onbruikbaar gemaakt kunnen worden .
(duplicate gateway ? . Allerlei HA spul dat een virtueel IP presenteert - duplicate dat virtuele HA ip .
De failover van clients naar een tweede DNS server is gewoonlijk pijnlijk merkbaar - 3x timeout op de eerste DNS server voordat ze naar de tweede gaan .
Wat je schrijft over die tool klinkt niet geweldig - maar een requirement "alles doet het gewoon als iemand een duplicate IP in het netwerk brengt" is m.i. niet iets waar enige leverancier op wil aftekenen . (juist degenen die wel wat snappen )
Dus niet voor rfc-1918 adressen.
Zo moeilijk is t niet om zelf een interne CA te gebruiken de software zit bij openssl.
[..]
Ach, ik ken een bedrijf dat ip tooling aanbiedt waarbij de techneut beweerde dat servers dynamische (dhcp) adressen moesten hebben. De tool was redundant uitgevoerd, en de redundante DNS servers zaten op 1 adres met tevens beheer op datzelfde adres. Zijn argument was dat een LAN iets anders is dan het internet. Drie maal raden wat er gebeurde toen een interne techneut per ongeluk datzelfde ip adres gebruikte voor iets anders... Bedrijf lag plat.
Ik snap het niet helemaal : grote storing wanneer een duplicatie IP voor een 'belangrijk' systeem aanwezig is : dat kan ik begrijpen .
Maar je lijkt te willen zeggen dat die tool die op dhcp-gebaseerde servers zat daar geen last van gehad had als de adressen statisch waren, ofzo ?
Ik moet zeggen dat met duplicate IPs - (als ik die mag aanwijzen) wel heel veel omgevingen, ook redundante onbruikbaar gemaakt kunnen worden .
(duplicate gateway ? . Allerlei HA spul dat een virtueel IP presenteert - duplicate dat virtuele HA ip .
De failover van clients naar een tweede DNS server is gewoonlijk pijnlijk merkbaar - 3x timeout op de eerste DNS server voordat ze naar de tweede gaan .
Wat je schrijft over die tool klinkt niet geweldig - maar een requirement "alles doet het gewoon als iemand een duplicate IP in het netwerk brengt" is m.i. niet iets waar enige leverancier op wil aftekenen . (juist degenen die wel wat snappen )
Nee, in mijn omgevingen gebeurt het niet dat servers op DHCP draaien, dat was hier ook niet het geval. Over my dead body. De externe techneut snapte niet wat de potentiele impact is van servers op DHCP. Niet geheel toevalligerwijze draaide ook DNS op die zelfde servers. Dat was een les voor die externe techneut die nu hopelijk wel begrijpt dat er geen verschil is voor dit soort diensten tussen een LAN, WAN of het internet. DNS en DHCP moeten hoog bereikbaar zijn en niet met 1 simpele fout onderuit te halen zijn. Redundantie en beheer op 1 enkel ip adres is gewoon dom.
[..]
Ach, ik ken een bedrijf dat ip tooling aanbiedt waarbij de techneut beweerde dat servers dynamische (dhcp) adressen moesten hebben. De tool was redundant uitgevoerd, en de redundante DNS servers zaten op 1 adres met tevens beheer op datzelfde adres. Zijn argument was dat een LAN iets anders is dan het internet. Drie maal raden wat er gebeurde toen een interne techneut per ongeluk datzelfde ip adres gebruikte voor iets anders... Bedrijf lag plat.
Ik snap het niet helemaal : grote storing wanneer een duplicatie IP voor een 'belangrijk' systeem aanwezig is : dat kan ik begrijpen .
Maar je lijkt te willen zeggen dat die tool die op dhcp-gebaseerde servers zat daar geen last van gehad had als de adressen statisch waren, ofzo ?
Ik moet zeggen dat met duplicate IPs - (als ik die mag aanwijzen) wel heel veel omgevingen, ook redundante onbruikbaar gemaakt kunnen worden .
(duplicate gateway ? . Allerlei HA spul dat een virtueel IP presenteert - duplicate dat virtuele HA ip .
De failover van clients naar een tweede DNS server is gewoonlijk pijnlijk merkbaar - 3x timeout op de eerste DNS server voordat ze naar de tweede gaan .
Wat je schrijft over die tool klinkt niet geweldig - maar een requirement "alles doet het gewoon als iemand een duplicate IP in het netwerk brengt" is m.i. niet iets waar enige leverancier op wil aftekenen . (juist degenen die wel wat snappen )
Nee, in mijn omgevingen gebeurt het niet dat servers op DHCP draaien, dat was hier ook niet het geval. Over my dead body. De externe techneut snapte niet wat de potentiele impact is van servers op DHCP. Niet geheel toevalligerwijze draaide ook DNS op die zelfde servers. Dat was een les voor die externe techneut die nu hopelijk wel begrijpt dat er geen verschil is voor dit soort diensten tussen een LAN, WAN of het internet. DNS en DHCP moeten hoog bereikbaar zijn en niet met 1 simpele fout onderuit te halen zijn. Redundantie en beheer op 1 enkel ip adres is gewoon dom.
Nogmaals : Als _ik_ één "fout" in jouw netwerk mag introduceren durf ik aardig hard te stellen dat het onbruikbaar is .
(duplicate GW IP ? rogue dhcp server , als je DHCP gebruikt ? access-list op any tcp/443 , of tcp/135 ofzo . primary resolver stuurt 127.0.0.1 als antwoord op elke query ) . Bij dat soort byzantijnse fouten helpt "redundancy" gewoon niet. )
Eisen dat een service blijft werken onder dergelijke omstandigheden is niet reeel .
En fors veel redundante services zijn gebouwd op het concept van 1 virtueel IP , dat dan 'HA' is en kan omzwaaien naar de actieve node . Inclusief redundante uplinks (vrrp/hsrp ) .
Ik ga wel mee met 'single homed _server_' is geen redundant concept, maar vertaling naar 'single IP' is niet terecht .
Echt - 8.8.8.8 is extreem redundant uitgevoerd ...
Je hebt vast wel gelijk dat de service die je kreeg niet goed opgezet was , of niet goed ontworpen . Maar je uitleg waarom is nogal kort door de bocht . Jij was erbij , en kent je omgeving . Dan sla je teveel stappen over om duidelijk te maken wat er slecht aan was.
Voor een on-prem server is dhcp voor het verkrijgen van server-IP inderdaad "ongebruikelijk" .
De rest , "single IP" - "het hangt ervan af" ; Genoeg netjes ontwerpen HA services dat een 'single VIP' gebruikt.
En eisen dat iets blijft werken bij een enkele menselijke configuratie "fout" is wel heel veel gevraagd , als de fout 'precies goed' uitpakt.
Bedenk overigens dat in cloud/container land het hele model van erg statisch geconfigureerde (IP)adressen voor 'services' heel hard omgegooid is .
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
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?