[gentoo-dev] friendly reminder wrt net virtual in init scripts

[gentoo-dev] friendly reminder wrt net virtual in init scripts

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

All,

I would like to remind everyone about the tracker for services that are
misusing "need net" in their OpenRC init scripts [1].

"need net" should be removed from our init scripts, because it is bogus
and breaks things. I also question the value of "use net", because the
same thinking applies, e.g. the net virtual really doesn't have a strong
meaning of any kind.

For more details, see the tracker and flameeyes' blog post.

Thanks,

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=439092

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts

[mingdao]

On Mon, Nov 04, 2013 at 09:30:07PM -0600, William Hubbs wrote:
> All,
> 
> I would like to remind everyone about the tracker for services that are
> misusing "need net" in their OpenRC init scripts [1].
> 
> "need net" should be removed from our init scripts, because it is bogus
> and breaks things. I also question the value of "use net", because the
> same thinking applies, e.g. the net virtual really doesn't have a strong
> meaning of any kind.
> 
> For more details, see the tracker and flameeyes' blog post.
> 
> Thanks,
> 
> William
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=439092

In that bug I read:

Flameeyes wrote the following blog post concerning this issue:

http://blog.flameeyes.eu/2012/10/may-i-have-a-network-connection-please

and the link gives me a (Error code: sec_error_ocsp_unknown_cert).
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

On Tue, 5 Nov 2013 08:49:15 -0600
mingdao <gentoo-dev@happypenguincomputers.com> wrote:

> and the link gives me a (Error code: sec_error_ocsp_unknown_cert).

The certificate expired; I guess it'll be fixed soon, as he gets back.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts

[Michael Orlitzky]

On 11/05/2013 09:49 AM, mingdao wrote:
> 
> Flameeyes wrote the following blog post concerning this issue:
> 
> http://blog.flameeyes.eu/2012/10/may-i-have-a-network-connection-please
> 
> and the link gives me a (Error code: sec_error_ocsp_unknown_cert).
> 

You should disable OCSP anyway. In Firefox, it's under,

  Edit -> Preferences -> Advanced -> Encryption -> Validation

The OCSP protocol is itself is vulnerable to MITM attacks, which is cute
when you consider its purpose.

Moreover, it sends the address of every website you visit to a third
party, which is the real reason to disable it IMO.

Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts

[mingdao]

On Tue, Nov 05, 2013 at 11:39:10AM -0500, Michael Orlitzky wrote:
> 
> You should disable OCSP anyway. In Firefox, it's under,
> 
>   Edit -> Preferences -> Advanced -> Encryption -> Validation
> 
> The OCSP protocol is itself is vulnerable to MITM attacks, which is cute
> when you consider its purpose.
> 
> Moreover, it sends the address of every website you visit to a third
> party, which is the real reason to disable it IMO.

Thanks for the information, Michael. My Firefox had a slightly different $PATH
as shown in the attached screenshot.

	Edit -> Preferences -> Advanced -> Certificates -> Validation

www-client/firefox-24.1.0-r1

(didn't do the upgrade to www-client/firefox-25.0-r1 today due to unstable
libpng-1.6.6 being pulled with the new subslot philosophy)
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts

[mingdao]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On Tue, Nov 05, 2013 at 11:02:17AM -0600, mingdao wrote:
> 
> Thanks for the information, Michael. My Firefox had a slightly different $PATH
> as shown in the attached screenshot.
> 
> 	Edit -> Preferences -> Advanced -> Certificates -> Validation
> 
> www-client/firefox-24.1.0-r1

Not that the attachment was important, but...
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

[-- Attachment #2: OCSP-firefox.png --]
[-- Type: image/png, Size: 253110 bytes --]

Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts

[Daniel Campbell]

On 11/05/2013 10:39 AM, Michael Orlitzky wrote:
> On 11/05/2013 09:49 AM, mingdao wrote:
>>
>> Flameeyes wrote the following blog post concerning this issue:
>>
>> http://blog.flameeyes.eu/2012/10/may-i-have-a-network-connection-please
>>
>> and the link gives me a (Error code: sec_error_ocsp_unknown_cert).
>>
> 
> You should disable OCSP anyway. In Firefox, it's under,
> 
>   Edit -> Preferences -> Advanced -> Encryption -> Validation
> 
> The OCSP protocol is itself is vulnerable to MITM attacks, which is cute
> when you consider its purpose.
> 
> Moreover, it sends the address of every website you visit to a third
> party, which is the real reason to disable it IMO.
> 
> 
Thanks for pointing this out! I'm a privacy-minded kind of guy and
didn't think to look there for possible violations. Do you know of any
other tips for locking down Firefox from prying eyes? I already use
NoScript and RequestPolicy, clean non-whitelisted cookies, and disabled
web forgery reporting in Preferences.

Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts

[Thomas D.]

[-- Attachment #1: Type: text/plain, Size: 5928 bytes --]

Hi,

Michael Orlitzky wrote:
> You should disable OCSP anyway. In Firefox, it's under,
> 
>   Edit -> Preferences -> Advanced -> Encryption -> Validation
> 
> The OCSP protocol is itself is vulnerable to MITM attacks, which is cute
> when you consider its purpose.
> 
> Moreover, it sends the address of every website you visit to a third
> party, which is the real reason to disable it IMO.

This is going OT but I cannot leave this statement uncommented, because
from my knowledge this is wrong/you are hiding important information
everyone should know about:

First, if you tell people they should disable OCSP you should also tell
these people the consequences: When you disable OCSP in Firefox, there
is *no* other way to know if a certificate was revoked or not. This is
because Firefox *never* downloaded any CRLs. Furthermore, they removed
the possibility to do that [1,2].

If you don't have the possibility to check a certificate for revocation,
the whole trust system cannot work because there is no way to tell
someone "Yes, it is nice that you trust me (=you trust the CA) and I
said you can trust this certificate (=the CA you trust has signed the
certificate in question) but now I changed my mind (=the CA has revoked
the certificate) so please don't trust this certificate anymore." Please
read "Would you knowingly trust an irrevocable SSL certificate?" [3].
And yes, this is a *real* problem, see [7].


Yes, there is a known MITM attacks against OCSP, see [4]. But this is
only possible due to bad default settings: Just change your OCSP setting
to *require* a valid answer. In Firefox:

  Edit -> Preferences -> Advanced -> Certificates -> Validation

Make sure

  When an OCSP server connection fails, treat the certificate
  as invalid

is checked (or you can just set "security.OCSP.require" to "TRUE").

If you are aware about any other know attacks, please share.


Regarding your privacy concerns:
No, your OCSP-enabled browser won't share the address (URL) with the
OCSP responder. Your browser will use the site's certificate serial
number to ask the OCSP responder if the certificate is still valid. Yes,
the company who is running the OCSP responder is able to log "You [IP,
UA...] requested status for certificates with the serial number 0x1,
0x2, 0x3" and because the OCSP responder needs some basic knowledge
about the certificates it should provide answers for, the operator may
know that the certificate with the serial number 0x1 has the Common Name
(CN) "www.mysecretsite.invalid" and 0x2 was issued for
"www.mydarksecrets.invalid" or 0x3 was for "www.facebook.com", but the
operator doesn't know the URL you visited.


I don't say OCSP is perfect. For example an OCSP check will delay the
initial SSL handshake, because your browser has to connect to the OCSP
responder when it has received the certificate from the server you are
connecting to. Depending on your connection and the OCSP responder, this
may take some time [5].

But the CRL system doesn't work anymore (and was never working in
Firefox, unless you manually added all the CRL distribution points for
your CA and Sub CAs...), because VerSign and other big SSL companies are
providing >20 MB CRLs. Imagine you would use your phone to visit a
website using some kind of mobile connection and it would have to fetch
50+ MBs in CRLs before the website will open...

Google for example decided some time ago to disable CRL checks too. They
will download CRLs for you and are planing to release these centralized
CRLs with normal updates. See [6].

They are improving OCSP. The next big thing is OCSP stapling [8,9] which
is now supported by all major browsers and patches are available for
most web servers.
OCSP stapling was developed to save the extra round trip to the OCSP
responder, but OCSP stapling-enabled websites will also "increase" your
privacy, because you don't longer have to tell the OCSP responder the
certificate (CN) you want to check.


If you are still really concerned about what OCSP may do to your
privacy, may I ask if you are also concerned about DNS servers? If not,
what's the difference between an OCSP responder which you ask for a
serial number, which can be resolved to a CN and a DNS server which you
ask for a ... CN? :)
Also, you are trusting a CA to secure your connections, but you don't
trust the same CA due to privacy concerns?


So please, don't just tell anybody to turn off OCSP. Tell them why you
may think they should do that. But also tell them about the new risks
they have to deal with so that they are able to decide on their own if
they want to disable OCSP or not.

PS: As long as you are trusting CAs and don't manage the trust of any
certificate you are using on your own I recommend to enable OCSP in all
your browsers and to treat any kind of invalid OCSP responses as a hard
failure, because I want to know if I can trust the certificate used to
secure my communication or not.

If you don't trust any CA, we don't have to talk about things like OCSP
or CRL and revocation...



See also:
=========
[1] http://thread.gmane.org/gmane.comp.mozilla.firefox.devel/290

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=867465

[3]
http://news.netcraft.com/archives/2013/05/23/would-you-knowingly-trust-an-irrevocable-ssl-certificate.html

[4] http://www.thoughtcrime.org/papers/ocsp-attack.pdf

[5] http://uptime.netcraft.com/perf/reports/OCSP

[6]
https://isc.sans.edu/diary/Chrome+to+stop+checking+Certificate+Revocation+List+%28CRL%29%3F/12556

[7]
http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html

[8] https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/

[9]
https://casecurity.org/2013/02/14/certificate-revocation-and-ocsp-stapling/


-- 
Regards,
Thomas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts

[mingdao]

On Wed, Nov 06, 2013 at 08:11:52PM +0100, Thomas D. wrote:
> Hi,
> 
> Michael Orlitzky wrote:
> > You should disable OCSP anyway. In Firefox, it's under,
> > 
> >   Edit -> Preferences -> Advanced -> Encryption -> Validation
> > 
> > The OCSP protocol is itself is vulnerable to MITM attacks, which is cute
> > when you consider its purpose.
> > 
> > Moreover, it sends the address of every website you visit to a third
> > party, which is the real reason to disable it IMO.
> 
> This is going OT but I cannot leave this statement uncommented, because
> from my knowledge this is wrong/you are hiding important information
> everyone should know about:
> 
> First, if you tell people they should disable OCSP you should also tell
> these people the consequences: When you disable OCSP in Firefox, there
> is *no* other way to know if a certificate was revoked or not. This is
> because Firefox *never* downloaded any CRLs. Furthermore, they removed
> the possibility to do that [1,2].
> 
> If you don't have the possibility to check a certificate for revocation,
> the whole trust system cannot work because there is no way to tell
> someone "Yes, it is nice that you trust me (=you trust the CA) and I
> said you can trust this certificate (=the CA you trust has signed the
> certificate in question) but now I changed my mind (=the CA has revoked
> the certificate) so please don't trust this certificate anymore." Please
> read "Would you knowingly trust an irrevocable SSL certificate?" [3].
> And yes, this is a *real* problem, see [7].
> 
> 
> Yes, there is a known MITM attacks against OCSP, see [4]. But this is
> only possible due to bad default settings: Just change your OCSP setting
> to *require* a valid answer. In Firefox:
> 
>   Edit -> Preferences -> Advanced -> Certificates -> Validation
> 
> Make sure
> 
>   When an OCSP server connection fails, treat the certificate
>   as invalid
> 
> is checked (or you can just set "security.OCSP.require" to "TRUE").
> 
> If you are aware about any other know attacks, please share.
> 
> 
> Regarding your privacy concerns:
> No, your OCSP-enabled browser won't share the address (URL) with the
> OCSP responder. Your browser will use the site's certificate serial
> number to ask the OCSP responder if the certificate is still valid. Yes,
> the company who is running the OCSP responder is able to log "You [IP,
> UA...] requested status for certificates with the serial number 0x1,
> 0x2, 0x3" and because the OCSP responder needs some basic knowledge
> about the certificates it should provide answers for, the operator may
> know that the certificate with the serial number 0x1 has the Common Name
> (CN) "www.mysecretsite.invalid" and 0x2 was issued for
> "www.mydarksecrets.invalid" or 0x3 was for "www.facebook.com", but the
> operator doesn't know the URL you visited.
> 
> 
> I don't say OCSP is perfect. For example an OCSP check will delay the
> initial SSL handshake, because your browser has to connect to the OCSP
> responder when it has received the certificate from the server you are
> connecting to. Depending on your connection and the OCSP responder, this
> may take some time [5].
> 
> But the CRL system doesn't work anymore (and was never working in
> Firefox, unless you manually added all the CRL distribution points for
> your CA and Sub CAs...), because VerSign and other big SSL companies are
> providing >20 MB CRLs. Imagine you would use your phone to visit a
> website using some kind of mobile connection and it would have to fetch
> 50+ MBs in CRLs before the website will open...
> 
> Google for example decided some time ago to disable CRL checks too. They
> will download CRLs for you and are planing to release these centralized
> CRLs with normal updates. See [6].
> 
> They are improving OCSP. The next big thing is OCSP stapling [8,9] which
> is now supported by all major browsers and patches are available for
> most web servers.
> OCSP stapling was developed to save the extra round trip to the OCSP
> responder, but OCSP stapling-enabled websites will also "increase" your
> privacy, because you don't longer have to tell the OCSP responder the
> certificate (CN) you want to check.
> 
> 
> If you are still really concerned about what OCSP may do to your
> privacy, may I ask if you are also concerned about DNS servers? If not,
> what's the difference between an OCSP responder which you ask for a
> serial number, which can be resolved to a CN and a DNS server which you
> ask for a ... CN? :)
> Also, you are trusting a CA to secure your connections, but you don't
> trust the same CA due to privacy concerns?
> 
> 
> So please, don't just tell anybody to turn off OCSP. Tell them why you
> may think they should do that. But also tell them about the new risks
> they have to deal with so that they are able to decide on their own if
> they want to disable OCSP or not.
> 
> PS: As long as you are trusting CAs and don't manage the trust of any
> certificate you are using on your own I recommend to enable OCSP in all
> your browsers and to treat any kind of invalid OCSP responses as a hard
> failure, because I want to know if I can trust the certificate used to
> secure my communication or not.
> 
> If you don't trust any CA, we don't have to talk about things like OCSP
> or CRL and revocation...
> 
> 
> 
> See also:
> =========
> [1] http://thread.gmane.org/gmane.comp.mozilla.firefox.devel/290
> 
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=867465
> 
> [3]
> http://news.netcraft.com/archives/2013/05/23/would-you-knowingly-trust-an-irrevocable-ssl-certificate.html
> 
> [4] http://www.thoughtcrime.org/papers/ocsp-attack.pdf
> 
> [5] http://uptime.netcraft.com/perf/reports/OCSP
> 
> [6]
> https://isc.sans.edu/diary/Chrome+to+stop+checking+Certificate+Revocation+List+%28CRL%29%3F/12556
> 
> [7]
> http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html
> 
> [8] https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
> 
> [9]
> https://casecurity.org/2013/02/14/certificate-revocation-and-ocsp-stapling/
> 
> 
> -- 
> Regards,
> Thomas

Thanks for the detailed explanation, Thomas.

Now, if any one of us turned off OCSP as Michael suggested, what should one do
after turning it back on? Could there now be certificates trusted there which
should not be?
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

[gentoo-dev] Re: friendly reminder wrt net virtual in init scripts

[Duncan]

Thomas D. posted on Wed, 06 Nov 2013 20:11:52 +0100 as excerpted:

> Michael Orlitzky wrote:
>> You should disable OCSP anyway. In Firefox, it's under,
>> 
>>   Edit -> Preferences -> Advanced -> Encryption -> Validation
>> 
>> The OCSP protocol is itself is vulnerable to MITM attacks, which is
>> cute when you consider its purpose.
>> 
>> Moreover, it sends the address of every website you visit to a third
>> party, which is the real reason to disable it IMO.
> 
> This is going OT but I cannot leave this statement uncommented, because
> from my knowledge this is wrong/you are hiding important information
> everyone should know about:

Thanks.  I was going to reply with something like this, but your reply 
was far better than mine would have been. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] OCSP Was: friendly reminder wrt net virtual in init scripts

[Duncan]

mingdao posted on Wed, 06 Nov 2013 14:13:34 -0600 as excerpted:

> Thanks for the detailed explanation, Thomas.
> 
> Now, if any one of us turned off OCSP as Michael suggested, what should
> one do after turning it back on? Could there now be certificates trusted
> there which should not be?

AFAIK, no... except possibly for any ongoing connections and any possible 
overrides you did during the "off" time.  New connections will 
automatically be checked again.

Meanwhile, another question for Thomas.  Is this "certificate stapling" 
the same thing google chrome is now doing for the google site, that 
enabled it to detect the (I think it was) Iranian and/or Chinese CA 
tampering, allowing them to say a "google" cert was valid that was 
actually their MitM cert, as appeared in the tech-news a few months ago?  
Or was that something different?

I had interpreted (well, I think I read, but either the journalist could 
have been mixed up too, or maybe I was misinterpreting what I read, 
either way the effect on my understanding is the same) the "certificate 
stapling" referred to at the time as indicating that google configured 
the certs for their own sites into chrome as shipped itself, effectively 
hard-coding them, NOT as google handling its own OCSP requests, as OCSP 
cert stapling does.  So now I'm wondering if I interpreted wrong then, or 
if there's actually two different things being referred to as certificate 
stapling, here.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts

[Thomas D.]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

Hi,

mingdao wrote:
> Now, if any one of us turned off OCSP as Michael suggested, what should one do
> after turning it back on? Could there now be certificates trusted there which
> should not be?

Well, only your current browser session can be affected. For Firefox:

  History -> Clear Recent History -> Details

In the dialog, just check "Active logins" and click "Clear Now".

This should clear any existing SSL state cache.


For Chrome it is a bit harder, because Chrome doesn't offer such an
option AFAIK (see [1]). Also, it depends on the SSL backend you are using.


PS: To enable OCSP in Chrome, go to chrome://settings/advanced

  Security
    Manage Certificates...
      Check for server certificate revocation

It is disabled by default, due to "performance concerns" :(



See also:
=========
[1] http://code.google.com/p/chromium/issues/detail?id=90454


-- 
Regards,
Thomas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts

[Michael Orlitzky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/06/2013 02:11 PM, Thomas D. wrote:
> 
> This is going OT but I cannot leave this statement uncommented,
> because from my knowledge this is wrong/you are hiding important
> information everyone should know about:

I figure everyone here is smart enough to google "OCSP" before
unchecking the box. This isn't the place to argue that the CA system
is broken, but I will respond to a few points.


> Yes, there is a known MITM attacks against OCSP, see [4]. But this
> is only possible due to bad default settings: Just change your OCSP
> setting to *require* a valid answer. In Firefox:
> 
> ...
> 
> If you are aware about any other know attacks, please share.
> 

Replay attacks, mentioned in the RFC (or Google). These could be
mitigated, but no one has bothered.



> Regarding your privacy concerns: No, your OCSP-enabled browser
> won't share the address (URL) with the OCSP responder. Your browser
> will use the site's certificate serial number to ask the OCSP
> responder if the certificate is still valid. Yes, the company who
> is running the OCSP responder is able to log "You [IP, UA...]
> requested status for certificates with the serial number 0x1, 0x2,
> 0x3" and because the OCSP responder needs some basic knowledge 
> about the certificates it should provide answers for, the operator
> may know that the certificate with the serial number 0x1 has the
> Common Name (CN) "www.mysecretsite.invalid" and 0x2 was issued for 
> "www.mydarksecrets.invalid" or 0x3 was for "www.facebook.com", but
> the operator doesn't know the URL you visited.

This is a long way of saying "it sends the address of every website
you visit to a third party."



> They are improving OCSP. The next big thing is OCSP stapling [8,9]
> which is now supported by all major browsers and patches are
> available for most web servers. OCSP stapling was developed to save
> the extra round trip to the OCSP responder, but OCSP
> stapling-enabled websites will also "increase" your privacy,
> because you don't longer have to tell the OCSP responder the 
> certificate (CN) you want to check.

That's cool, but it doesn't exist now and won't for years. And as a
visitor you have no way of knowing whether the server supports it (==
your privacy will be kept).



> If you are still really concerned about what OCSP may do to your 
> privacy, may I ask if you are also concerned about DNS servers? If
> not, what's the difference between an OCSP responder which you ask
> for a serial number, which can be resolved to a CN and a DNS server
> which you ask for a ... CN? :)

Only two DNS servers are involved; mine and those of the domain I'm
visiting.


> Also, you are trusting a CA to secure your connections, but you
> don't trust the same CA due to privacy concerns?

You're conflating two things here. I trust AES to keep my connection
safe. I don't send my data to the CA.


> If you don't trust any CA, we don't have to talk about things like
> OCSP or CRL and revocation...

Well there we agree. Why would you trust the CAs? You don't know them
personally and you aren't their customer.

Do you trust the governments of the USA and China? (Hint: you
shouldn't.) If the answer is no, then you don't trust the CA system.
So whether or not you trust them to revoke that authentication is a
moot point.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJSeuYkAAoJEBxJck0inpOigpUP/3AqhOXf3D5nPzHZumJw9iv6
/9eXu2MMgoZTdwILAc0GnlSwnstTgaI/WZYFHRsU24DQsCQxCMr8VnJnirRNv0Zz
EB+fu3i991e85BloxaZaC3nDcJ5cDB3WjEOfUi4adHVEaY71eAKlwge2P9jG2t9B
60HslYxK9pBhmCzqfpxViunSZV36w4mGOSB9X8ajagkklW4BGzP508czzX0KU/HH
zBxhRxowuLKzIKQZ0R996bEk7b0STadNbTllSyF4850Iftm9Aj+smYHXmbO5wT1I
lYWJGP11bAZfbObstG+ZepST98FxsZGke80LicydNIvZ13tnqYLYERYdxb9GVMB/
/hO4wi53ltvEtb6/7uy/ec3jg5x8V3e6ZidHu/4ObToYZF4gzsNZ8agLazFEHA54
Xpk3+nh8ypJPBdBiJZuuYQckUFwXzTpEXqpfb5X6c38F6pOxNElexuAa57coIqoy
M8ZsMoTr3oCYsRC5lRFmb6uv9WZZDi6iRSTh5z78fzxc3/ynF7SYmJIQEIKzZDnn
FxEAjjhLrJtFCkfFWd1GaIJjrwLjcX+laMJrx6zqkjG3BvQRGTvO2md5m7WoX0v9
0MmxfMsjkQpDV7e/w4gxNG6aZzf1kvBZXPhdFuLJM1NEbD40xoJC90E+y9LsENbV
++m0ObSQf+JfCMcqH0BS
=PbZR
-----END PGP SIGNATURE-----

Re: [gentoo-dev] OCSP Was: friendly reminder wrt net virtual in init scripts

[Thomas D.]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

Hi,

Duncan wrote:
> Meanwhile, another question for Thomas.  Is this "certificate stapling" 
> the same thing google chrome is now doing for the google site, that 
> enabled it to detect the (I think it was) Iranian and/or Chinese CA 
> tampering, allowing them to say a "google" cert was valid that was 
> actually their MitM cert, as appeared in the tech-news a few months ago?  
> Or was that something different?
> 
> I had interpreted (well, I think I read, but either the journalist could 
> have been mixed up too, or maybe I was misinterpreting what I read, 
> either way the effect on my understanding is the same) the "certificate 
> stapling" referred to at the time as indicating that google configured 
> the certs for their own sites into chrome as shipped itself, effectively 
> hard-coding them, NOT as google handling its own OCSP requests, as OCSP 
> cert stapling does.  So now I'm wondering if I interpreted wrong then, or 
> if there's actually two different things being referred to as certificate 
> stapling, here.

No, OCSP Stapling is something else.

Guess you are talking about HSTS and "SSL pinning" [1,2]: In Google
Chrome, they hard coded some certificates/certificate meta data [3]
which must be present in every certificate used for any Google site.

If you connect to a Google site for example and this site will use a
certificate from a CA not specified in [3] (depending on the service,
they may also verify against a list of known fingerprints like EV SSL is
working), connection will be terminated and the browser will send some
details to Google so they get noticed.



See also:
=========
[1]
http://blog.chromium.org/2011/06/new-chromium-security-features-june.html

[2] https://www.imperialviolet.org/2011/05/04/pinning.html

[3] http://www.googblogs.com/uncategorized/changes-to-our-ssl-certificates/


-- 
Regards,
Thomas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] OCSP was: friendly reminder wrt net virtual in init scripts

[Alex Xu]

[-- Attachment #1: Type: text/plain, Size: 4221 bytes --]

On 06/11/13 08:00 PM, Michael Orlitzky wrote:
> On 11/06/2013 02:11 PM, Thomas D. wrote:
> 
>> This is going OT but I cannot leave this statement uncommented,
>> because from my knowledge this is wrong/you are hiding important
>> information everyone should know about:
> 
> I figure everyone here is smart enough to google "OCSP" before
> unchecking the box. This isn't the place to argue that the CA system
> is broken, but I will respond to a few points.

I figure everyone here is smart enough not to spread knowingly-incorrect
propaganda.

> 
>> Yes, there is a known MITM attacks against OCSP, see [4]. But this
>> is only possible due to bad default settings: Just change your OCSP
>> setting to *require* a valid answer. In Firefox:
> 
>> ...
> 
>> If you are aware about any other know attacks, please share.
> 
> 
> Replay attacks, mentioned in the RFC (or Google). These could be
> mitigated, but no one has bothered.
> 
> 
> 
>> Regarding your privacy concerns: No, your OCSP-enabled browser
>> won't share the address (URL) with the OCSP responder. Your browser
>> will use the site's certificate serial number to ask the OCSP
>> responder if the certificate is still valid. Yes, the company who
>> is running the OCSP responder is able to log "You [IP, UA...]
>> requested status for certificates with the serial number 0x1, 0x2,
>> 0x3" and because the OCSP responder needs some basic knowledge 
>> about the certificates it should provide answers for, the operator
>> may know that the certificate with the serial number 0x1 has the
>> Common Name (CN) "www.mysecretsite.invalid" and 0x2 was issued for 
>> "www.mydarksecrets.invalid" or 0x3 was for "www.facebook.com", but
>> the operator doesn't know the URL you visited.
> 
> This is a long way of saying "it sends the address of every website
> you visit to a third party."

Addresses, in the context of web browsing, are commonly understood to
mean URLs, which include protocol, name, port, and path.

OCSP only sends the "name" portion. Thus, the statement was a long way
of saying "you are wrong.".

> 
> 
>> They are improving OCSP. The next big thing is OCSP stapling [8,9]
>> which is now supported by all major browsers and patches are
>> available for most web servers. OCSP stapling was developed to save
>> the extra round trip to the OCSP responder, but OCSP
>> stapling-enabled websites will also "increase" your privacy,
>> because you don't longer have to tell the OCSP responder the 
>> certificate (CN) you want to check.
> 
> That's cool, but it doesn't exist now and won't for years. And as a
> visitor you have no way of knowing whether the server supports it (==
> your privacy will be kept).

DH3, and incorrect. Firefox, Apache, and nginx all support OCSP stapling
RIGHT NOW.

> 
>> If you are still really concerned about what OCSP may do to your 
>> privacy, may I ask if you are also concerned about DNS servers? If
>> not, what's the difference between an OCSP responder which you ask
>> for a serial number, which can be resolved to a CN and a DNS server
>> which you ask for a ... CN? :)
> 
> Only two DNS servers are involved; mine and those of the domain I'm
> visiting.

Not necessarily. "Your" name server may in fact not be a recursive name
server, but delegate some portion to a recursive name server.

> 
>> Also, you are trusting a CA to secure your connections, but you
>> don't trust the same CA due to privacy concerns?
> 
> You're conflating two things here. I trust AES to keep my connection
> safe. I don't send my data to the CA.

You're conflating two things here. If you trust the CA, you trust them
not to perform a MitM attack.

> 
>> If you don't trust any CA, we don't have to talk about things like
>> OCSP or CRL and revocation...
> 
> Well there we agree. Why would you trust the CAs? You don't know them
> personally and you aren't their customer.
> 
> Do you trust the governments of the USA and China? (Hint: you
> shouldn't.) If the answer is no, then you don't trust the CA system.
> So whether or not you trust them to revoke that authentication is a
> moot point.
> 

False dichotomy.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts

[Thomas D.]

[-- Attachment #1: Type: text/plain, Size: 3366 bytes --]

Hi,

Michael Orlitzky wrote:
>> If you are aware about any other know attacks, please share.
> 
> Replay attacks, mentioned in the RFC (or Google). These could be
> mitigated, but no one has bothered.

The OCSP response is signed. The signature contains a time stamp. If
your clock is right, replay attacks are only possible for the expected
lifespan of the response. But because it is expected that an OCSP
response is valid for x hours, it is not a real problem.

But sadly there are some CA which are serving pre-generated OCSP
responses which are valid for 7 days (like their CRLs). 7 days can be
very long... :(


> This is a long way of saying "it sends the address of every website
> you visit to a third party."

See Alex's reply. I wanted to make it clear to everyone, that the
address isn't the full URL.


>> If you are still really concerned about what OCSP may do to your 
>> privacy, may I ask if you are also concerned about DNS servers? If
>> not, what's the difference between an OCSP responder which you ask
>> for a serial number, which can be resolved to a CN and a DNS server
>> which you ask for a ... CN? :)
> 
> Only two DNS servers are involved; mine and those of the domain I'm
> visiting.

Again, please see Alex's reply. Also, if you are using your *own* DNS
server, you are *special*. But most people will use the DNS server from
their ISP. And I wasn't talking about *special* people who are able to
run everything in their own trusted environment.


>> Also, you are trusting a CA to secure your connections, but you
>> don't trust the same CA due to privacy concerns?
> 
> You're conflating two things here. I trust AES to keep my connection
> safe. I don't send my data to the CA.

CAs not only issue certificates. They should also make sure that they
only issue "secure" certificates:

  - Require a secure signing algorithm
  - Require a secure key size

You could use the best algorithm available. But if the certificate's
private key is shared with others, others are able to decrypt the
captured secure traffic.

The CAB forum for example says that no CA is allowed to create the key
used for any issued customer certificate.

So when you are using a pre-populated list of trusted CAs you are also
expecting that these CAs are doing their jobs right.

IF you don't do that, you shouldn't use them.


>> If you don't trust any CA, we don't have to talk about things like
>> OCSP or CRL and revocation...
> 
> Well there we agree. Why would you trust the CAs? You don't know them
> personally and you aren't their customer.
> 
> Do you trust the governments of the USA and China? (Hint: you
> shouldn't.) If the answer is no, then you don't trust the CA system.
> So whether or not you trust them to revoke that authentication is a
> moot point.

Well, that's another discussion. As said before, we don't have to talk
about these things if you don't trust a system called "Web of trust" :)

But because most people "live" in this (broken) system (this is
reality!), do you still think telling them they should disable OCSP,
which will actually disable an important feature (again, without OCSP
you are unable to check a certificate for revocation in Firefox) and
make them vulnerable to a new threat is a good thing?


-- 
Regards,
Thomas


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] OCSP was: friendly reminder wrt net virtual in init scripts

[Gordon Pettey]

On Wed, Nov 6, 2013 at 7:36 PM, Alex Xu <alex_y_xu@yahoo.ca> wrote:
> On 06/11/13 08:00 PM, Michael Orlitzky wrote:
>> On 11/06/2013 02:11 PM, Thomas D. wrote:
>>
>>> This is going OT but I cannot leave this statement uncommented,
>>> because from my knowledge this is wrong/you are hiding important
>>> information everyone should know about:
>>
>> I figure everyone here is smart enough to google "OCSP" before
>> unchecking the box. This isn't the place to argue that the CA system
>> is broken, but I will respond to a few points.
>
> I figure everyone here is smart enough not to spread knowingly-incorrect
> propaganda.

>>> Regarding your privacy concerns: No, your OCSP-enabled browser
>>> won't share the address (URL) with the OCSP responder. Your browser
>>> will use the site's certificate serial number to ask the OCSP
>>> responder if the certificate is still valid. Yes, the company who
>>> is running the OCSP responder is able to log "You [IP, UA...]
>>> requested status for certificates with the serial number 0x1, 0x2,
>>> 0x3" and because the OCSP responder needs some basic knowledge
>>> about the certificates it should provide answers for, the operator
>>> may know that the certificate with the serial number 0x1 has the
>>> Common Name (CN) "www.mysecretsite.invalid" and 0x2 was issued for
>>> "www.mydarksecrets.invalid" or 0x3 was for "www.facebook.com", but
>>> the operator doesn't know the URL you visited.
>>
>> This is a long way of saying "it sends the address of every website
>> you visit to a third party."
>
> Addresses, in the context of web browsing, are commonly understood to
> mean URLs, which include protocol, name, port, and path.
>
> OCSP only sends the "name" portion. Thus, the statement was a long way
> of saying "you are wrong.".

A bit of additional consideration:

Given the above statement and RFC 2560, OCSP sends the certificate serial,
not the name. With the availability of "Wildcard" certificates and the
subjectAltName parameter, with many certificates that serial will not let the
CA actually know which domain you are visiting.

[gentoo-dev] Re: OCSP Was: friendly reminder wrt net virtual in init scripts

[Duncan]

Thomas D. posted on Thu, 07 Nov 2013 02:00:29 +0100 as excerpted:

> Duncan wrote:
>> Meanwhile, another question for Thomas.  Is this "certificate stapling"
>> the same thing google chrome is now doing for the google site, that
>> enabled it to detect the (I think it was) Iranian and/or Chinese CA
>> tampering, allowing them to say a "google" cert was valid that was
>> actually their MitM cert, as appeared in the tech-news a few months
>> ago? Or was that something different?
> 
> No, OCSP Stapling is something else.
> 
> Guess you are talking about HSTS and "SSL pinning" [1,2]: In Google
> Chrome, they hard coded some certificates/certificate meta data [3]
> which must be present in every certificate used for any Google site.

That was it, yes.  Thanks greatly for clearing up my confusion. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman