67 replies to this topic

[WanWizard]

HTTPS op zich zuigt niet, maar de manier waarop het nu wordt opgdrongen wel.

 

HTTPS biedt twee voordelen, encryptie in transit, en server validatie. Beide zijn voor heel veel toepassingen helemaal niet nodig, en de laatste is alleen maar zinvol bij EV certificaten (en zelfs dan tonen niet alle browsers de eigenaar direct). Het feit dat een website een geldig certificaat heeft (en dus bv een groen slotje laat zien) zegt absoluut nul over de betrouwbaarheid ervan.

[MiLo]

HTTPS biedt twee voordelen, encryptie in transit, en server validatie. Beide zijn voor heel veel toepassingen helemaal niet nodig, ...

Voor de toepassing niet maar voor security wel.

Encryptie zonder validatie is zinloos, want een man-in-the-middle blijft onopgemerkt. Zonder validatie is de key-exchange te volgen en kun je de inhoud decrypten. Als er een share-secret gebruikt wordt, is dat trouwens impliciet de validatie en blijft de regel zonder validatie geen encryptie gewoon gelden.

Validatie zonder encryptie werkt ook niet, een man-in-the-middle kan de validatie gewoon laten passeren en pas daarna ingrijpen en de inhoud van de berichten onopgemerkt wijzigen. Biedt dus geen bescherming tegen het spoofen van een website.

[Erik Slagter]

Blijf WanWizard's punt overeind, voor heel veel toepassingen is het niet nodig. Met het mooie voorbeeld van "bijdragen" op social media.

[WanWizard]

Ik bedoelde meer "server validatie" door de gebuiker, niet zo zeer technisch.

 

Maar ik ben het niet helemaal eens met MiLo, er zijn zat situaties waarbij een self-signed certificate meer dan voldoende is, en daar valt weinig aan te valideren. Bijvoorbeeld omdat de kans op MITM of spoofing quasi nul is. 

[MiLo]

Dan heb je me niet begrepen.

Een self-signed certificate is juist veel veiliger dan een "gekochte". Je hebt dan alles in eigen beheer, en dus minder kans op uitlekken. Bovendien kun je ook veel preciezer bepalen wat er wel en niet mee gebeurt. Wat wel heel belangrijk is, en dat wordt vaak vergeten, is dat de verificatie een handmatige eenmalige actie zal zijn (tenzij je een windows domein hebt, dan kun je certificaten pushen) en die MOET handmatig zijn. Bijvoorbeeld door die op het bedrijfsnetwerk in te lezen. Zonder handmatige verificatie is het certificaat waardeloos en daarmee de verbinding ook niet veilig.

[WanWizard]

Heb je het nu over client-side certficates (want die kan Windows pushen)? Want dat is natuurlijk weer een andere discussie.

[MiLo]

In mijn tijd bij OCE meen ik te herinneren dat je vanuit de domain server allerlei "trust" kon pushen. Dat gebruikte ik om een nieuwe printer vertrouwd te maken in het domain. Printer genereert een certificaat, en stuurt die naar de admin. Als die die hem approved had, kon het hele domain secure printen zonder verder nog gevraagd te worden.

Leuke demo, de hele printerinstallatie werd dan:
- Aanzetten
- Smartcard van (printer) administrator in de gleuf steken (geen pin nodig)
- Printer is nu geconfigureerd voor het hele domein (alle domain users mogen printen, admin heeft beheer)
- Domain admin krijgt een Certificate request, deze approven (op domain admin's werkplek) en printer is ook helemaal klaar voor HTTPS.

[WanWizard]

Ik heb dit systeem gebruikt om 802.1x certificaten te pushen naar PC's, vanuit Microsoft's Radius implementatie.