On 17.06.2016 19:57, ????????? ???????? wrote:>>> Then OCSP stapling is the way to go but it could be a real PITA to >>> setup for the first time and may not be supported by older browsers >>> anyway. >>> >> not really, because the same server tells the client that the SSL >> certificate is good, as the SSL certificate itself; >> these must be independent; > > Says who?the logic; anything you do to reduce problems or to prevent problems connecting to SSL sites because of slow OCSP servers or similar reduces security itself ...> Yes, the OCSP response comes from the same server but it's still > signed by the issuer CA.yes and no, but faking a valid OCSP response that says good instead of revoked is also possible ...> OCSP stapling has been developed for a number of reasons including > user privacy concerns and I find those reasons quite convincing.the primary reason was to prevent problems for connection problems - or whatever problems - in connection with the OCSP> The need to revoke an issued certificate before its expiration date is > rare.maybe; but Heartbleed showed us something different ...;> Yet the origial OCSP implementation gives the interested third parties > the ability to track browsing habits of unsuspecting visitors of the > sites which do not implement OCSP stapling. This is not to mention > much higher traffic the CAs will have to shoulder with the > proliferation of secure sites. >of course; if there would be only one CA, and there would be only SSL, this CA would know what hosts you connect in your browser, because of OCSP ... but the privacy concerns in this connections is less than the tracking cookies where a little bit more of information is sent ... (with OCSP they know only which IP address is verifying which certificate and what time)
> yes and no, but faking a valid OCSP response that says good instead of > revoked is also possible ...Could you please provide any proof for that statement? If it were true the whole PKI infrastructure should probably be thrown out of the window. )> the primary reason was to prevent problems for connection problems - > or whatever problems - in connection with the OCSPSure. I've never said privacy concerns were the main reason. Security concerns can probably be addressed with reducing update interval of issuer-signed OCSP responses. For my free wosign certificates ii's 4 days and my understanding is that interval matches CRL update policy of the CA. Per RFC2560 (see nextUpdate below): 2.4 Semantics of thisUpdate, nextUpdate and producedAt Responses can contain three times in them - thisUpdate, nextUpdate and producedAt. The semantics of these fields are: - thisUpdate: The time at which the status being indicated is known to be correct - nextUpdate: The time at or before which newer information will be available about the status of the certificate - producedAt: The time at which the OCSP responder signed this response. If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time.
On 17.06.2016 22:39, ????????? ???????? wrote:>> yes and no, but faking a valid OCSP response that says good instead of >> revoked is also possible ... > > Could you please provide any proof for that statement? If it were true > the whole PKI infrastructure should probably be thrown out of the > window. )question back: is the SHA2 discussion a real security impact or just paranoia? so provide a proof of the following statement: "using OCSP Stapling is as secure as not using OCSP Stapling" just think of the "parallel universe" called real life ... do you believe a car dealer that a used car is ok, or do you want a proof by third party? (here the car dealer is the server and 3rd pardy is the OCSP server or CRL provided by the CA) for me I refuse it or in other words, when there is no OCSP response and I don't get a CRL from the CA the SSL-host is blocked;