Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Certificaten wel of niet vervangen?

09-04-2014, 00:41 door Anoniem, 8 reacties
Moet je nu wel of net je certificaten vervangen naar aanleiding van die heartbleed bug?
Reacties (8)
09-04-2014, 10:12 door Anoniem
niet, het certificaat is niet gecompromitteerd maar de verwerking van de gedecrypte data staat in een 64k toegankelijk geheugen. Alleen als je known text aanval vermoed is het handig je cert te updaten.
09-04-2014, 10:15 door Anoniem
Sterker nog.. De private keys. Jet was via de bug namelijk mogelijk om delen of de gehele private key te stelen uit het geheugen.
09-04-2014, 10:39 door Anoniem
Je moet de impact per geval beoordelen. Dit kun je alleen doen als je weet wat allemaal in het relevante proces draait (eg mod_php).

Wat in elk geval (potentieel) gelekt is:

- private key van het certificaat. De oplossing is dus niet alleen een nieuw certificaat ! Je MOET een nieuwe key gebruiken.
- request data, denk hier bij aan tokens, cleartext wachtwoorden, sessie cookies.

Als php in hetzelfde process draait heb je een groter probleem; Interne tokens (eg shared secrets, api keys) kunnen dan gelekt zijn.
09-04-2014, 10:51 door Anoniem
Door Anoniem: niet, het certificaat is niet gecompromitteerd maar de verwerking van de gedecrypte data staat in een 64k toegankelijk geheugen. Alleen als je known text aanval vermoed is het handig je cert te updaten.

Het is zeker nodig om beide te vervangen, de keys en de certs die ermee gesigned zijn volgens heartbleed.com:

What is leaked primary key material and how to recover?

These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.
09-04-2014, 12:04 door Anoniem
http://blog.cryptographyengineering.com/ =>

"Revoke your certificate(s) and get a new one; fix is equally simple. Just add a bounds check:

+ /* Read type and payload length first */
+ if (1 + 2 + 16 > s->s3->rrec.length)
+ return 0; /* silently discard */
+ hbtype = *p++;
+ n2s(p, payload);
+ if (1 + 2 + payload + 16 > s->s3->rrec.length)
+ return 0; /* silently discard per RFC 6520 sec. 4 */
+ pl = p;
+

"
09-04-2014, 17:36 door Anoniem
Eerst de fix en dan nieuwe sleutels. Ja dus, wel certificaten vervangen. En wachtwoorden.
12-04-2014, 19:05 door Anoniem
Ja. Fixen. Dan eerst een nieuwe PRIVATE KEY genereren, want daar gaat het om. En met die key een nieuwe CSR genereren of nieuw certificaat ondertekenen.
15-04-2014, 15:09 door Anoniem
En dit over een maand nog een keer doen, want er komt deze maand nog wat extra shit bij...
Kwestie van even afwachten...
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.