5 ms·
The most obvious thing being that it describes primarily RSA-handshake and RC4 encryption. For good reasons these aren't used any more. But there's plenty of t
by hannob 6y ago
The most obvious thing being that it describes primarily RSA-handshake and RC4 encryption. For good reasons these aren't used any more.
But there's plenty of tiny details that are obsolete as well, e.g. it describes the timestamp which is no longer used and usually filled with random data these days.
- londons_explore 6y agoIt's a shame the clients timestamp is no longer sent to the server. If it was, a server could compensate for a client clock being wrong by many decades by providing an old expired certificate.
- spockz 6y agoIf this was the behaviour of an app up to 2009 you could at least serve certificates to those apps still.
- forgotmypw17 6y agoThis is one of the reasons I still use http primarily and do not promote https. There are many barriers to an https connection, and this is one of them. Another is the version race, meaning browsers as recent as 2012 are no longer compatible with today's https sites.
- Shared404 6y agoWhile I understand where you are coming from, and in fact use http on my personal site, I have to disagree about which is better. For the Web (Meaning HTTP/S), compatibility back past 5-6 years seems kind of pointless. There's to much changing to fast at too many layers to be a really good target, unless you are serving an actually static site (Which is not a bad thing, it's what I do). Even then, HTTPS still has value, as it can prevent ISP's from injecting advertisements. I don't believe this is currently a large issue in the US, but I remember a recent discussion about bad behaviour by ISP's in India and other countries. Edit: I do however believe that (for a static site on https) it is a good idea to allow a fall back to http, assuming of course that you are fine with the contents being mitm'd. Also, I think the Gopher is a good thing to serve in this kind of situation.
- vbezhenar 6y agoWhy client does not accept certificate from the future? What attack is supposed to be prevented?
- toast0 6y agoX.509 cerrificates have a not before and a not after date, so validators check them. It's a real pain when you have to let a certificate sit for a day to compensate for clients with poorly set clocks or poorly written date comparisons.
- tialaramex 6y agoGoogle's experiments suggest that the vast majority of clients are off by an hour (incorrect "daylight saving" adjustments / next door's timezone) or less. They did do work on having clients with Internet access just bootstrap a roughly correct time from first principles, but I don't know if Chrome/ Android do this out of the box. Public Issuers generally backdate certificates by a small amount of time to allow for that one hour. This is permitted (unlike backdating to avoid other rules) by the Baseline Requirements, so you should find you don't need to wait before using the certificates you are issued.
- toast0 6y ago> so you should find you don't need to wait before using the certificates you are issued. Thanks, but no. I had to wait about 12 hours to deploy replacement certificates after Heartbleed, in order to balance cert errors with loss of privacy. A large number of the clients I had to support interpret the dates as local time, which isn't helpful when they're in the western hemisphere and GoDaddy wouldn't backdate certs at all. Last I had a cert issued, DigiCert set not before to the order time even for re-issues or duplicates, so that was a lot easier to manage.
- a1369209993 6y agoThis is true, but doesn't actually answer the question of what attack respecting the not-before date is supposed to prevent.