[Users] [Bulk] Re: [Bulk] Re: Certificate pop-up message
ma1l1ists at yahoo.co.uk
Fri Oct 5 10:43:56 CEST 2012
> > It seems you can't differentiate between an actually expired
> > certificate and one the computer believes is expired! The RFC refers
> > to an actually expired certificate. Your barking up the wrong tree.
> Certificate expiration dates are checked and validated by the client.
> Read the RFCs; they state this as requirements for the SSL handshake.
> If the client computer's clock is wrong and this leads to the false
> determination that a certificate has expired then it is the client
> computer's owner fault.
SSL works just fine with an incorrect clock. Crackpot?, that makes you
part of the problem and RFCs are by definition incorrect striving for
improvements, hence Request For Comments.
In any case as I said the time is used but you were inaccurate and ssl
is fine here. The incorrect RFC is HSTS. The time of client and server
is known by both sides and can be used for fingerprinting as it is sent
in plain text and could be modified even.
The RFC you pointed out says so.
gmt_unix_time: The current time and date in standard UNIX 32-bit
format according to the sender's internal clock. Clocks are not
required to be set correctly by the basic SSL protocol; higher
level or application protocols may define additional requirements.
> You'll run into the same kinds of problems with authentication systems
> like APOP. The APOP name digest uses a MD5 hash of several pieces of
> data including a decimal representations of the client and server
> system clocks. If client and server times don't match up then
> authentication fails because the hashes won't match.
Why would I use apop, it's about as secure as a duck in an aristocrats
pond ;-) Of course my friend might but he doesn't and I'd suggest a
new server before he did.
'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
More information about the Users