471723 - Reject certs that expired before the date the browser was compiled, regardless of system clock setting

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement)

Description

[Jesse Ruderman]

During discussion of http://www.win.tue.nl/hashclash/rogue-ca/, someone pointed out that an attacker who is able to hijack your https connections might also be able to alter your system clock by hijacking your NTP connections.  (I don't know whether this is true.)

The fix for bug 471715 could prevent the MD5-collision certificate from being used in this way, but what about other expired certs?  Some expired certs might already be compromised, and others might have weaknesses that we've been ignoring because they are expired.  (Again, I don't know whether this is true.)

I think Firefox builds compiled in 2009 should reject certs that expired before 2009, regardless of the system clock setting.

Comment 1

[Matthias Versen [:Matti]]

This is a good idea !

A usual ntp client should reject (AFAIK) a synchronization if the time difference exceeds value X and windows for example synchs only once per day.
An Attacker must MITM the connection over a very long time but that's not impossible if i read the case in bugzilla about the user who used an open wifi.

Comment 2

[Daniel Veditz [:dveditz]]

Would this be a PSM feature or something that would have to go into NSS? Where does the compilation date come from?

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

This sounds like 
  "NSS should know the correct date, even if the system doesn't".
My reaction to that is: um, yeaaaah.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

No, I misread the request.  Could be done in NSS, I think.  
But I could see complaints about binary compatibility.
Would definitely be safe to do in PSM.

Comment 5

[Gervase Markham [:gerv]]

http://groups.google.com/group/comp.protocols.time.ntp/browse_thread/thread/202f87466ad68b04 says:

"NTP has a default max adjustment of about 1000 seconds", which is just under 17 minutes.

Therefore, using NTP to progressively set a machine's clock back far enough to be able to use an expired certificate for which you have somehow obtained the private key seems like a perverse way of exploiting complete control over someone's internet connection. There are surely far easier ways of attacking. And, of course, the computer user may notice and correct the serious inaccuracy in their clock long before you got the clock to a usable value.

I therefore submit that this fix is unnecessary.

Gerv

Comment 6

[timeless]

gerv: NTP is two things, a protocol and an implementation. ntp the unix application is not the only implementation. the response you linked to was written by someone who used poor casing. the original author was clearly aware of the distinction and asked properly. the respondent was clearly talking about the implementation because he mentioned a define.

http://technet.microsoft.com/en-us/library/cc773263.aspx

MaxNegPhaseCorrection
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Version
Windows XP, Windows Vista, Windows Server 2003, and Windows Server 2008

This entry specifies the largest negative time correction in seconds that the service makes. If the service determines that a change larger than this is required, it logs an event instead. Special case: 0xFFFFFFFF means always make time correction. The default value for domain members is 0xFFFFFFFF. The default value for stand-alone clients and servers is 54,000 (15 hrs).

Unless i'm missing something, 15hrs is slightly more realistic for attacking than your 17mins.

I'm having trouble figuring out how often windows would be willing to accept updates. five years could be lost in 3500 updates. Each would have to be registered as "persistent", which i believe means it'd have to have sent consistent values for the period.

If a client decides every minute that it's received consistent input indicating that it's wrong by 15hrs, then a device sitting in a room for ~2 days would be off by 4-5 years.

I'd imagine someone could find a cert which expired a year ago instead of 5 years ago, because either way the CRL should in general no longer contain certificate.

Comment 7

[Gervase Markham [:gerv]]

Yeah, OK, my mistake, I assumed that the default in the reference implementation would be used everywhere.

matti said that Windows checks once a day, so the attack is still pretty hard if the computer is used at all.

Gerv

Comment 8

[Justin Dolske [:Dolske]]

I'm wary of having the browser do this, because it feels a bit like bandaiding what's really a system security problem... If the system clock is vulnerable to adjustment by an attacker, I'd expect that to be a problem for the OS vendor to address, not individual applications. [And if not, should the browser also be scanning the system for other insecure services and configurations? Malware/spyware is a problem that affects large number of users right now.]

OTOH, I suppose sanity checking the time would be a simple layer of defense. And some form of checking might also be useful in the context of people who have accidentally set their system clock to, say, "today's date, 1909". ISTR there being occasional bugs filed by such people wondering why Firefox is broken.

Comment 9

[Ben Bucksch (:BenB)]

This could be an alternative approach for bug 471715.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Maybe what's needed is for the browser to check to see if the system date
is before the date on which the browser was compiled, and if so, warn
the user and refuse to honor ANY certs at all, saying "With your system 
clock set so far in the past, none of the security assurances of SSL are
available to you."

Comment 11

[Kai Engert [:KaiE:]]

Fixing this bug will break machines used in time traveling environments.

Comment 12

[Kai Engert [:KaiE:]]

Sometimes we attempt to verify a certificate for a specific timestamp, which may be in the past. An example is signed email, where we might be interested whether the signature was valid at the time of sending.

I guess such a scenario is the reason for Nelson's concerns from comment 4 ?

I think we would have to restrict this "lower timestamp bound" to those code executions that attempt to verify a cert against the "now" timestamp.

Whenever we verify something against the "now timestamp", ensure that 
  now >= build time

If 
  now < build time
then 
  set now = build time 
  for the verification call.

I think this logic could be equally used in both NSS or PSM, and I'd prefer this to happen in NSS. I think this logic would not cause compatibility problems for NSS (except in the time travel scenario ;-) ).


Fixing this bug can cause weird effects in environments where the build machine lacks time synch and has a date in the future.

What about OCSP requests? When they ask about "now", should those requests use the build time as the lower timestamp bound, too?

What about environments that deliberately use a system date from the past? Maybe some closed environment chooses to set all dates back by 1 year, maybe in 30 years, after the year 2038 32-bit unix time overflow? Such environments would be required to recompile Mozilla (assuming we embed the build time inside the binary).

Not sure my environments are likely, just trying to think of unusual scenarios, to make sure we are certain this is the right thing to do.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #11)
> Fixing this bug will break machines used in time traveling environments.

To whom will this be a greater concern?  The Eloi? or the Morlocks?  

But seriously, for a long time, I advocated that signatures on emails 
should continue to appear to be good even after the cert has expired.
However, in Trunk versions of Thunderbird and Firefox, this has not been
the case for at least a year now.  This MAY be due to the use of OCSP.
OCSP responders always reject inquiries about expired certs. 

So, given that signatures on messages whose signer's certs expired after 
the message was written no longer appear valid, I see little point in 
trying to preserve functionality that no longer works, and that is simply 
below the Thunderbird radar.

Comment 14

[Ben Bucksch (:BenB)]

Nelson, that would of course be a bug. Can you file it, please?
Later verification of emails definitely is important and being actively discussed, at least for some communities, e.g. government.

Comment 15

[Kai Engert [:KaiE:]]

Well, sigh. My description was the intended behavior. But indeed, about 1 year ago we changed the mail verification to verify emails against "now", instead of the signature timestamp. It was because of a security concern, see bug 324474

Comment 16

[Ben Bucksch (:BenB)]

Filed bug 482799 about Thunderbird S/MIME signature verification after a year.

Comment 17

[David Tombs]

As Kai implies, seems like this change is too far-reaching with too many possible complications. An even more common scenario would be setting system time back for testing purposes, maybe even for testing the exact expire cert issue. I'd say this scenario would be more common than the NTP forging.

If this is implemented, at least make it an run-time option, please.

Comment 18

[timeless]

personally, i see the mail and web cases as distinct, and note that this is filed explicitly about 'browser', not 'mail'.

i wouldn't strictly speaking oppose a hidden pref for disabling this, however, i would absolutely oppose a user visible pref for disabling this, and i think we should do this and enable it by default....

kaie's algorithm seems fine w/ me. There are two possible impls that I can see, one is a new API to NSS which lets the client say "I was built on <x>", a client could choose not to call this api. The alternative, which I'm not really a fan of would be for the NSS library to know when it was built.

The reason I don't favor the latter is that I expect the NSS library to change less often than firefox, and I'd like the system to have a moving baseline.

Comment 19

[Eddy Nigg (StartCom)]

I find it funny that correct system time is of interest only for certificates. Shouldn't the application warn the user AT ALL that his system time isn't set correctly and this might result into various unexpected behaviors (including certificates)?

Comment 20

[timeless]

very little of the system actually cares about time. if a web page doesn't use Date() then the only things that will be adversely affected are Cache and Cookies, and the user could probably survive w/ both being somewhat flaky.

The thing is that we don't like putting UI into the user's face at startup/launch/first-run/..., it gets them really annoyed. And since the only part of the process that really cares about time is crypto, then, that's pretty much the part of the process which gets to try to explain to the user why it matters.

Comment 21

[Dana Keeler (she/her) (use needinfo) [:keeler]]

I don't think this is necessary, particularly considering the attack it addresses boils down to "attacker convinces user to add a certificate error override".