Hacker News Reader

Comment by some_furry | Hacker News Reader

Are these dates correct?

  An initial report of a possible timing side channel was made on 14th July 2020
  by Hubert Kario (Red Hat). A refined report identifying a specific timing side
  channel was made on 15th July 2022 by Hubert Kario.
  The fix was developed by Dmitry Belyavsky (Red Hat) and Hubert Kario.

If so, it's interesting that it took exactly 2 years and 1 day for the refined report.

EDIT: By interesting I just mean "an amusing coincidence" or "possibly a typo", nothing weird.

View on HN

Yes, the dates are correct.

Why is that interesting?

It's interesting because it looks like it could be a typo on the year (2022 -> 2020), if the date turns out to not be correct. That's all.

Is taking 2 years to address a vulnerability normal?

Maybe in this case! You can look at P1v15 RSA and assume that there might be some kind of behavior oracle, which is definitely not the same thing as demonstrating that there is a viable oracle. A problem with P1v15 in general is that you have to mitigate these kinds of covert channels directly.

But I assume the comment above was suggesting there was something more interesting than the magnitude of the lag.

> But I assume the comment above was suggesting there was something more interesting than the magnitude of the lag.

Nothing insidious, just thought maybe it could have been a typo. But if not, then it's just an amusing coincidence.

Taking 2 years to demonstrate the impact of a difficult or strange cryptographic bug isn't really that interesting in and of itself.

Right, especially in this case where you can almost just go from TLS library to TLS library saying "hm, this implements P1v15, probably has a timing channel" to get credit for the eventual finding. :)

Right. In a lot of cases "this implements RSA" and "this wasn't written by Thomas Pornin" is enough to suspect a timing channel. Writing a proof of concept for one is at least an order of magnitude more challenging; at least in my experience. (I am way better at mitigation than exploit development.)

Everybody is!

Good to know! (I thought maybe this was just my own biases or weaknesses showing. I've been trying to work on it this year when I have time.)

“I think there may be a bug but I can’t reproduce it” is quite common

I just managed to repot use a bug in a vision system that I saw in august. Finally managed to reproduce it mostly last week.

It took 2 years to find out that a potential vulnerability actually exists. There's a lot of potential vulnerabilities that may or may not actually be exploitable.

2 year was frequently the length of ssl certificates (they’ve since dropped to 1 year)

Or maybe it’s a coincidence.

It was never 2 years as it's not 1 year now. It's specified in days (397 currently, 825 and 1185 days before).

For a long time it was months. The original BRs say 60 months (ie 5 years) and then moving to 39 months in 2015. That 1185 days you listed wasn't ever actually in a written document, it's how Chromium browsers generously estimate 39 months.

But yes, none of it matters any more. Apple insisted on 398 days, they decided it is a compliance issue, so all legit leaf certificates in the Web PKI that haven't expired have a maximum lifespan of 398 days.

People tend to think about it as a year or two years because the way a for-profit CA used these limits was to sell annual certificates but allow early renewal without losing out. Say you bought a cert on June 10th 2022, this year as the end of May approaches you get an email (In reality use automation, please) saying hey, you should renew soon. You can pay up on 29th of May, you get a new certificate which expires on... June 10th 2024. They couldn't do that if the rules didn't allow enough extra days.

The CA/B forum lost a lot of credibility with me, the vote failed and it took a single member (Apple) to tell everyone else that they were going to ignore the vote and proceed anyways.

No debate, no re-vote, no giving anyone any extra time or warning.

That's how it should work: the major browser vendors and their root programs should be calling the shots. Participation in CA/B is a favor they do the CA industry, nothing more. The rise of activist browser root programs correlates with essentially everything good that has happened in the WebPKI.

Reply on news.ycombinator.com