Oh boy. I wonder how many other companies that have previously been lax about validating that cert revocation is handled correctly by their devices are going to validate the eMudrha cert revocation and discover that they are not, in fact, handling revocation correctly. Yikes.
This caught my eye, remember how the eMudhra certificates had weirdly low parameters, like 4 and others in the single digits?
"Mbed TLS - Medium, CVSS 5.9 - A buffer-length typo reduces a 2048-bit DH modulus to one byte. TLS 1.2 DHE_RSA sessions are decryptable when the client accepts the broken parameters. GOAHEAD-SA-2026-0005."
Not familiar with those implementation details but was this the root cause?
The first sizeof(dhm_g) should have been sizeof(dhm_p). So, do you attribute this to a simple typo (hard to catch at a glance due to similar letter shapes), "single letter variable names are bad" but the wikipedia page on DH also calls them p and g - it takes a little digging to get that "root" and "modulus" would have been better names, but maybe having them directly match the most common form of the equation would have made them easier to review...
Or do you just add it to the list of C crimes, that "passing storage length and pointer" is maybe the worst possible way to return written-to storage from a function :-)
At first glance I almost misread this as a different C crime, since the declarations aren't in scope... uint8_t dhm_p[2048]; and uint8_t *dhm_p = (...)malloc(2048); both make dhm_p a reasonable pointer to 2k bytes of storage and are totally suitable for that argument, but sizeof the first one is 2048 and sizeof the second one is 4 (or more likely 8 these days, but this is specifically code from an embedded web server so I can say 4 :-)
But no, the actual problem was so much less subtle.
"Mbed TLS - Medium, CVSS 5.9 - A buffer-length typo reduces a 2048-bit DH modulus to one byte. TLS 1.2 DHE_RSA sessions are decryptable when the client accepts the broken parameters. GOAHEAD-SA-2026-0005."
Not familiar with those implementation details but was this the root cause?
Or do you just add it to the list of C crimes, that "passing storage length and pointer" is maybe the worst possible way to return written-to storage from a function :-)
But no, the actual problem was so much less subtle.