Userbase

Ik ben bezig met mij te verdiepen in PKI via een eigen CA server. Het doel is om te leren hoe verschillende systemen met elkaar encrypted kunnen communiceren. Intussen heb ik zelf een CA server kunnen opzetten met behulp van EJBCA (Open Source PKI).
Wat er nu moet gebeuren om bijvoorbeeld FreeNAS (domain joined) encrypted te laten communiceren met een Samba based domain controller blijft voor mij zeer vaag.
Een how-to welke dit exact uitlegt heb ik nog niet kunnen vinden, of ik gebruik de verkeerde keywords.

Wel heb ik volgende uitleg even bekeken maar het blijft vaag
- https://smallstep.com/blog/everything-pki.html
- https://www.techopedia.com/definition/2 ... ity-server

Graag had wat ik raad gehad om dit toch te begrijpen.

Samba heeft built-in encryption, afhankelijk van de smb versie, dat volgens mij volledig afzonderlijk van een PKI staat ... je CA is vooral om SSL certificaten te voorzien, waarom je zelfs een aparte software hebt gebruikt i.p.v. de Windows CA (daar je reeds Windows servers hebt) is me een raadsel.

Leg eens uit wat je wil bekomen, en zoek dan de oplossing. Eerst iets implementeren om daarna daar je problemen proberen mee op te lossen is niet echt de goede aanpak

Een zeer makkelijke manier om een CA op te zetten zijn de easy-rsa scripts die bij OpenVPN zitten. Ik gebruik ze vrijwel wekelijks.

In de enterprise ook al gebruikt voor bvb een syslog-ng SSL aware te maken bij een PCI compliant speler, met je eigen root CA dan toegevoegd aan alle nodes die moeten kunnen loggen, en per logger dan een signed cert.

https://openvpn.net/community-resources ... anagement/

Je CA kan enkel certificaten aanmaken/signen/revoken.

Waarvoor je je certs will gebruiken hangt af van:
-Waarvoor het certificaat kan dienen (purpose)
-Welke andere tech die je gebruikt.(bijvoorbeeld je webserver die het gebruikt voor HTTPS, je VPN die het kan gebruiken om je verbinding te encrypteren)

Er is trouwens ook een verschil in symmetrische/asymmetrische encryptie.

Certificaten dienen enkel om de identiteit van de andere partij vast te stellen.

Partij a genereert een geheim, encrypteert dit geheim met de pubkey van de andere kant b, die het enkel kan decrypteren met zijn private key. B decrypteert het, en stuurt het dan in plaintext terug naar a. Zo weet a dat b effectief b is, want enkel hij kan het decrypteren. Uiteraard moet je steeds een nieuw geheim kiezen, anders kan je een replay attack toepassen.

Je kan dit ook toepassen voor logs: in een PCI omgeving wil je wel kunnen loggen, maar je wil niet dat een systeembeheerder de logs kan lezen. Dus log je naar een centrale doos via een SSL tunnel, en die centrale doos encrypteert de logs dan naar de pubkey van een geauthoriseerde reader. De personen die dan toegang hebben tot deze reader, worden sterk gecontroleerd. Zo kan je dus secure loggen van transacties, zonder dat eender wie kan meekijken.

Als ze mekaar willen authenticeren (en daar loopt het bij SSL dus vaak fout, de client auth enkel de server, maar de server auth niet de client) dan gebeurt hetzelfde in de andere richting. Als je wil gaan loggen door een SSL tunnel, dan moet de server de client uiteraard ook authen, want anders kan elke client in naam van een andere server logs sturen. Een VPN is dan weer een mooi voorbeeld waar ze mekaar authen, je wil niet dat eender wie op je VPN geraakt, en de client wil ook zeker zijn dat de server effectief de server is, en niet een hacker met een MITM attack.

Je zou deze challenge response in plaintext kunnen doen, maar veel beter is dat ze eerst een key exchange doen, om dit via symmetrische encryptie te doen.

Zo werkt bvb SSH, ze doen eerst een KEX met diffie hellman (en liefst eentje met voldoende sterke moduli), en dan hebben ze beide een symmetrische key samengesteld die niet door een derde partij achterhaald kan worden (tenzij je exchange zwakke crypto gebruikt, zie weakdh.org), en binnen deze tunnel kunnen ze dan mekaar authenticeren met het bovenstaande. Ook je standaard HTTPS werkt gelijkaardig.

Als je het SSH protocol leest, dan kom je dit soort zaken tegen. Dit is o.a. mijn job nu bij een grote speler, om dit soort zaken dicht te timmeren ;-
Ik krijg regelmatig audits van scans van onze SSL en SSH poorten en dan komt al het bovenstaande regelmatig terug.

Encryptie is een vak apart (en vaak superslecht uitgevoerd); dat is het eerste dat je moet weten.

Dan moet je oppassen waar je je CA en PKI voor wil gebruiken.
Verschillende systemen gebruiken verschillende implementaties.

Het DNSSEC systeem bv werkt met KSKs en ZSKs (key signing keys en zone signing keys).
Het principe daar is dat je je KSK laat signen door een authority, en dat je die enkel gebruik om je eigen ZSKs mee te signen.
Zo kan je makkelijker van keys wisselen zonder opnieuw aan een authority een signature moeten te vragen.

Het VPN systeem werkt vaak met eigen CAs; ofwel met CA op enterprise niveau en intermediate op bedrijfsniveau.
Bv OpenVPN: dan creeer je een eigen CA, die op zijn beurt voor elke server en client een certificate aanmaakt.
Vergeet dan ook geen revocation authority te maken.

ub4b schreef:Certificaten dienen enkel om de identiteit van de andere partij vast te stellen.
Partij a genereert een geheim, encrypteert dit geheim met de pubkey van de andere kant b, die het enkel kan decrypteren met zijn private key. B decrypteert het, en stuurt het dan in plaintext terug naar a. Zo weet a dat b effectief b is, want enkel hij kan het decrypteren.

Dat is een oversimplificatie van het gebruik van assymetric encryption.
Je verwart verder ook het gebruik van certs met het gebruik van assymetric encryption.
Trouwens, in dat vb weet B niet wie A is, dus veilig is het niet.


Key Exchanges hebben hun eigen nut; bij een Diffie Hellmann (vaak gebruikt in VPN om de authentication step af te werken) worden 2 private keys met mekaar vermengd tot een shared secret key.

Hashes zijn nog een andere vorm van encryptie; deze zorgen ervoor dat het verzonden bericht tamper-proof is, want de voorberekende hash kan alleen maar overeen komen als de inhoud van het bericht onveranderd is.
Dit principe wordt overigens ook toegepast voor signatures: daar wordt de hash geencrypteerd met een private key, zodat de hash comparison alleen maar kan werken als 1) de inhoud identiek is, en 2) de public key overeenkomt met de private key, maw de juiste persoon gekozen is.

Eeuwig probleem is dat PKI APIs altijd geschreven zijn met het idee dat de persoon die het implementeert al genoeg van encryption kent.
Het is dan ook iets moeilijks om juist te implementeren en zeer makkelijk kapot te krijgen als je iets verkeerd doet.

Hoeveel web developers nog nooit van salting gehoord hebben, zijn niet meer te tellen; laat staan dat ze fatsoenlijk hun pwds zouden hashen.
Het aantal mensen die denken dat Base64 encoding ook encryptie is, is evenmin te tellen.
Zelfs de ganse Italiaanse electronische betaalinfrastructuur heeft lang op base64 gedraaid, van wat ik hoor uit de industrie.

Sasuke schreef:Samba heeft built-in encryption, afhankelijk van de smb versie, dat volgens mij volledig afzonderlijk van een PKI staat ... je CA is vooral om SSL certificaten te voorzien, waarom je zelfs een aparte software hebt gebruikt i.p.v. de Windows CA (daar je reeds Windows servers hebt) is me een raadsel.

Leg eens uit wat je wil bekomen, en zoek dan de oplossing. Eerst iets implementeren om daarna daar je problemen proberen mee op te lossen is niet echt de goede aanpak

Het is een Linux test/leer omgeving, in Windows heb ik het nog nooit opgezet maar het principe zal wel hetzelfde zijn.
In Samba, welke als DC functioneert, kan je TLS inschakelen. Als eerste probeersel was het plan om dan een fileserver (FreeNAS), in het domain te joinen. Op de fileserver is er dan toch een certificate nodig, wat uit de CA server komt.

Het is me niet duidelijk hoe ik het certifcaat verhaal van A tot Z opzet. Er zijn bijvoorbeeld allerlei files die gegenereerd moeten worden. Hoe maak ik deze via de CA server aan en waar moet elke file komen? Welke moeten op de Samba DC en op de fileserver. etc...

ITnetadmin schreef:

ub4b schreef:Certificaten dienen enkel om de identiteit van de andere partij vast te stellen.
Partij a genereert een geheim, encrypteert dit geheim met de pubkey van de andere kant b, die het enkel kan decrypteren met zijn private key. B decrypteert het, en stuurt het dan in plaintext terug naar a. Zo weet a dat b effectief b is, want enkel hij kan het decrypteren.

Dat is een oversimplificatie van het gebruik van assymetric encryption.
Je verwart verder ook het gebruik van certs met het gebruik van assymetric encryption.
Trouwens, in dat vb weet B niet wie A is, dus veilig is het niet.

Ik was de eerste in België die certified was voor PGP, dus ik denk wel dat ik begrijp hoe dit werkt. Een certificaat zoals typisch gebruikt op het internet kan enkel werken dankzij pub/private crypto, en dat is een toepassing van asymetrische crypto.

In het gesimplificeerd voorbeeld gaf ik ook duidelijk aan dat er meer nodig was, en dat beide partijen mekaar moeten authenticeren om safe te spelen. Uiteraard om zeker te zijn, moeten beide kanten ook nog eens gesigned zijn door een root CA.

Finaal is de sessie zelf symmetrisch, maar om tot een opbouw te komen van een gezamelijke session key met symmetrische crypto, wordt asymetrische crypto gebruikt en zaken zoals KEX / diffie hellman of zelfs straffer nog, elliptic curve ipv de klassieke textbook diffie hellman.