Timeline for How does adding a random serial number improve a certificate's security?
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 16, 2023 at 22:54 | comment | added | Charlieface | Good. Like I said "SHA256 or SHA2" doesn't really make sense, you should recommend one or the other because SHA256 is itself a subset of the SHA2 algorithm | |
| Jan 16, 2023 at 22:49 | comment | added | D.W. | @Charlieface, thank you. I've removed the recommendation of SHA1. | |
| Jan 16, 2023 at 22:48 | history | edited | D.W. | CC BY-SA 4.0 |
deleted 8 characters in body
|
| Jun 7, 2012 at 17:23 | comment | added | makerofthings7 | Seems that NONCES are used to prevent OSPF replays, Windows server supports it, Windows Clients don't technet.microsoft.com/en-us/library/… | |
| Jun 6, 2012 at 16:46 | comment | added | makerofthings7 | If the answer to that previous comment is "Yes" it makes me want to remove every MD5 root cert, and ban any MD5 intermediate from ever touching my system. | |
| Jun 6, 2012 at 16:41 | comment | added | makerofthings7 | One example may be where the attacker wants to reuse a stolen/hacked key that was revoked. Since the CRLs aren't persisted locally and expire in RAM over time, I think a spoofed CRL could be used to permit what was previously denied, making the CRL worthless. In other words since this is based on DNS & HTTP I would think it means that all the DNS hacks apply. So can I conclude that all HTTP-based (CRL or OCSP) communications are unsecure unless IPSec and DNSSec are used? | |
| Jun 6, 2012 at 16:25 | comment | added | D.W. | @makerofthings7, I don't know! I'd guess yes, the same logic applies. It is possible that the severity might be lower (maybe the only thing that an attacker do is forge a revocation, which is probably much less serious than forging a cert; forging a revocation is primarily a denial-of-service or annoyance attack). These are just guesses, though. | |
| Jun 6, 2012 at 12:02 | comment | added | makerofthings7 | I found some CRL and OCSP signatures that are MD5. Should I suppose your logic applies there as well too? | |
| Jun 6, 2012 at 4:34 | comment | added | D.W. | @makerofthings7, no, this advice primarily targets certs that use MD5. Sha384ECDSA uses SHA384 as its hash algorithm, not MD5. There are no known collision attacks on SHA384 that are practically feasible. The attacks only apply to MD5. Therefore, the attacks don't apply to Sha384ECDSA. That said... like I wrote at the end, you could always use serial numbers anyway for defense-in-depth (e.g., in case someone discovers a new attack on the hash). It's not believed to be necessary, given our current understanding of these algorithms, but I guess it can't hurt. | |
| Jun 6, 2012 at 4:24 | comment | added | makerofthings7 | Does the same advice apply to a cert signed with sha384ECDSA? Anything special I should watch out for with that one? | |
| Jun 6, 2012 at 2:07 | vote | accept | makerofthings7 | ||
| Jun 6, 2012 at 2:05 | comment | added | makerofthings7 | Incredible info. I never knew it worked this way. This has been added to the linked Q&A Checklist on how to build a CA? | |
| Jun 6, 2012 at 1:50 | history | edited | D.W. | CC BY-SA 3.0 |
added 1700 characters in body; added 703 characters in body
|
| Jun 6, 2012 at 1:43 | history | answered | D.W. | CC BY-SA 3.0 |