headers
weizhong qiang | 3 Feb 03:49
Picon

Re: how to get CKA_PRIVATE_EXPONENT attribute from a private key?

hi,
I solved the problem by generating the key pair with "isPerm" to be PR_FALSE, and then importing the private
key using PK11_ImportDERPrivateKeyInfoAndReturnKey.

Best Regards,
Weizhong Qiang

On Jan 31, 2012, at 7:28 AM, weizhong qiang wrote:

> hi Robert and others,
> See the attachment for more complete test case of generating and reading a key.
> I found if I set the "isPerm" parameter to be PR_FALSE (see line 78 of the test case), the private key is not sensitive.
> If I set the "isPerm" parameter to be PR_TRUE, then not mater the "IsSensitive" (the next parameter after
"isPerm") is PR_TRUE or PR_FALSE, the private key always sensitive. 
> Is it a feature?
> 
> Thanks and Best Regards,
> Weizhong Qiang
> 
> 
> <test_nssprivatekey.cpp>
> 
> On Jan 28, 2012, at 4:16 PM, weizhong qiang wrote:
> 
>> hi,
>> 
>> On Jan 27, 2012, at 6:52 PM, Robert Relyea wrote:
>> 
>>> On 01/26/2012 11:53 PM, weizhong qiang wrote:
>>>> hi,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Engert | 6 Feb 21:21
Picon
Favicon

Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure

On 21.10.2011 15:09, Kai Engert wrote:
> This is an idea how we could improve today's world of PKI, OCSP, CA's.
>
> https://kuix.de/mecai/
>
> Review, thoughts and reports of flaws welcome.

Thanks to Peter Eckersley, who first mentioned to me at 28c3 that there 
is one scenario that isn't solved by the MECAI proposal. Meanwhile 
several people have mentioned this to me, including people at Fosdem and 
a comment from today in "reddit".

If the attacker is able to hack the router that is close to the 
webserver (e.g. hack the ISP that hosts the webserver), then the 
attacker might be able to simply apply for a certificate from a CA and 
intercept the (plaintext) approval emails the CA sends to the domain's 
mail server.

In other words, the problem is, an attacker could ask for a certificate 
without the domain owner noticing.

Here's one solution I could think of: In addition to everything already 
done, maybe we should require that issueing a certificate requires 
(additional) phone call(s).

We have:
- attacker
- CA
- domain owner
- domain owner's phone number or ISP's phone number in the domain registry
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ondrej Mikle | 7 Feb 17:54
Picon
Favicon

Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure

Hi,

Kai Engert wrote:
> If the attacker is able to hack the router that is close to the
> webserver (e.g. hack the ISP that hosts the webserver), then the
> attacker might be able to simply apply for a certificate from a CA and
> intercept the (plaintext) approval emails the CA sends to the domain's
> mail server. 

[...snip...]

> The phone calls would ensure that each registered person will be aware
> of the certificate issuance. 

This is getting very close to EV validation (Sovereign Keys have the
same issue).

How do you plan on handling CDN services (ones with many certs)?
Convergence and Perspectives suffer from that as well.

Another weak point I see is the DNS server for the domain (only
exception for this seems to be Transparent Certificates and EV
validation; everything else is susceptible - DANE, Sovereign Keys...).

What about this attack scenario:

1. attacker compromises DNS server for domain.com or redirects NS record
2. now of course he can get DV-validated cert and MitM mails (in
contrary to the "attacker close to webserver", now it does not matter
where MX for domain.com pointed to)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Engert | 7 Feb 18:04
Picon
Favicon

Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure

My previous message was a proposed solution to the problem "attacker is 
close to the server and uses it to obtain a new fraudulent cert", and I 
proposed to use an organizational approach to prevent that attack.

In addition, another potential attack is, the attacker has obtained a 
certificate from a "hacked CA", so that no approval process was 
necessary. In addition the attacker is close to the router, so that the 
routes from most (or even all) other CAs can be controlled by the 
attacker, which means the routes from all vouching authorities can be 
controlled by the attacker. With the solution described so far, MECAI 
wouldn't be helpful, because all CAs would happily produce a voucher for 
the attacker.

I hope we can come up with an incremental solution for this attack 
vector on top of the current MECAI proposal.

Here is an initial idea for a solution. It requires that vouching 
authorities keep a record of the recently seen certificates. Whenever a 
server desires to switch to a newer certificate, the server must use TLS 
client authentication with any of the recently seen certificates.

More detailed description:

(Note I mix the terms CA and vouching authority, but both should refer 
to the vouching authority.)

In the beginning, the CA's bookkeeping state for an IP address is empty. 
The first time a CA receives a request for vouching for a new IP address 
with no previous state (or with an expired state), the vouching 
authority will only check the ownership of the certificate (requires
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kai Engert | 7 Feb 21:58
Picon
Favicon

Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure

On 07.02.2012 17:54, Ondrej Mikle wrote:
>> The phone calls would ensure that each registered person will be aware
>> of the certificate issuance.
>
> This is getting very close to EV validation (Sovereign Keys have the
> same issue).

I'd say making phone calls is less effort than checking business 
documents, so I'm not convinced it's close to EV - because EV is out of 
reach for anyone running a private server.

> How do you plan on handling CDN services (ones with many certs)?

That's a reason why I propose vouchers to be IP specific.

In my understanding, each IP will have only a single certificate, 
regardless from where in the world you connect to it.

> Another weak point I see is the DNS server for the domain (only
> exception for this seems to be Transparent Certificates and EV
> validation; everything else is susceptible - DANE, Sovereign Keys...).
>
> What about this attack scenario:
>
> 1. attacker compromises DNS server for domain.com or redirects NS record
> 2. now of course he can get DV-validated cert and MitM mails (in
> contrary to the "attacker close to webserver", now it does not matter
> where MX for domain.com pointed to)

EV doesn't help if the attacker simply decides to get a plain DV cert
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kyle Hamilton | 8 Feb 00:24
Picon

Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure

Why not just use the secure domain transfer identifier?  Only the real holder of the domain has that.

-Kyle H

On Mon, Feb 6, 2012 at 12:21 PM, Kai Engert <kaie <at> kuix.de> wrote:
> On 21.10.2011 15:09, Kai Engert wrote:
>>
>> This is an idea how we could improve today's world of PKI, OCSP, CA's.
>>
>> https://kuix.de/mecai/
>>
>> Review, thoughts and reports of flaws welcome.
>
>
>
> Thanks to Peter Eckersley, who first mentioned to me at 28c3 that there is
> one scenario that isn't solved by the MECAI proposal. Meanwhile several
> people have mentioned this to me, including people at Fosdem and a comment
> from today in "reddit".
>
> If the attacker is able to hack the router that is close to the webserver
> (e.g. hack the ISP that hosts the webserver), then the attacker might be
> able to simply apply for a certificate from a CA and intercept the
> (plaintext) approval emails the CA sends to the domain's mail server.
>
> In other words, the problem is, an attacker could ask for a certificate
> without the domain owner noticing.
>
> Here's one solution I could think of: In addition to everything already
> done, maybe we should require that issueing a certificate requires
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ondrej Mikle | 8 Feb 13:43
Picon
Favicon

Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure

On 02/07/2012 09:58 PM, Kai Engert wrote:
> On 07.02.2012 17:54, Ondrej Mikle wrote:
>>> The phone calls would ensure that each registered person will be aware
>>> of the certificate issuance.
>>
>> This is getting very close to EV validation (Sovereign Keys have the
>> same issue).
> 
> I'd say making phone calls is less effort than checking business
> documents, so I'm not convinced it's close to EV - because EV is out of
> reach for anyone running a private server.

Sure, provided that you call the right owner.

>> How do you plan on handling CDN services (ones with many certs)?
> 
> That's a reason why I propose vouchers to be IP specific.
> 
> In my understanding, each IP will have only a single certificate,
> regardless from where in the world you connect to it.

It's not true in general. There are services hidden with a load-balancer
behind a single IP. An example - 3m.com:

% dig +short 3m.com
192.28.34.26  #note: it's not fast-flux, TTL is 86400

% openssl s_client -tls1 -connect 192.28.34.26:443 -servername 3m.com
</dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256
-issuer -subject
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rob Stradling | 8 Feb 13:59
Favicon

Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure

On 08/02/12 12:43, Ondrej Mikle wrote:
> On 02/07/2012 09:58 PM, Kai Engert wrote:
<snip>
>> That's a reason why I propose vouchers to be IP specific.
>>
>> In my understanding, each IP will have only a single certificate,
>> regardless from where in the world you connect to it.
>
> It's not true in general. There are services hidden with a load-balancer
> behind a single IP. An example - 3m.com:

Also, a TLS Server might choose a different cert depending on the cipher 
suite list provided by the TLS client.

e.g.

$ openssl s_client -connect tls.secg.org:40023 -cipher RSA 2> /dev/null 
| grep "Certificate chain" -A 3
Certificate chain
  0 s:/OU=SAMPLE ONLY/O=Certicom 
Corp./L=Toronto/SN=Ontario/CN=tls.secg.org RSA 1024 Server Certificate/C=CA
    i:/OU=SAMPLE ONLY/O=Certicom 
Corp./L=Toronto/SN=Ontario/CN=tls.secg.org RSA 1024 Certificate 
Authority/C=CA
---

vs

$ openssl s_client -connect tls.secg.org:40023 -cipher ECDSA 2> 
/dev/null | grep "Certificate chain" -A 5
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ondrej Mikle | 8 Feb 14:43
Picon
Favicon

Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure

On 02/07/2012 06:04 PM, Kai Engert wrote:
> The CA will remember the assocation {IP, certificate}. In future
> requests, as long as this requesting IP requests a voucher for the same
> certificate, the described bidirectional authentication and verification
> will be sufficient.

Just a technicality: {IP, list of certificates, FQDN} instead of {IP,
certificate} (see my previous post to dev.tech.crypto).

We should also investigate how various cloud services (Amazon, Akamai,
...) handle IP-to-server mapping. I don't know how often does that change.

> What happens if an attacker uses a false certificate for a domain that
> is not yet using SSL? The worst that can happen is a temporary denial of
> service attack to start using SSL, because it makes it harder for the
> real domain owner to switch away from the false bookkeeping, which is
> being kept by the vouching authorities. However, as soon as the false
> certificate used by the attacker has been revoked, the vouching
> authorities will revert to the "empty" bookkeeping state. Also, because
> vouchers are per IP, the real domain owner can simply ensure that a
> different IP address will be used for the real server. Also, it should
> probably be defined that the bookkeeping done by vouching authorities
> (the pairs of {IP, certificate}) will expire 10 days after no more
> requests using a valid certificate were made for the given IP.

Sovereign Keys need to solve the same issue:
https://git.eff.org/?p=sovereign-keys.git;a=blob;f=issues/transitional-considerations.txt;h=fa3b1591820baf1f2f62740f1f0e8b7998c29174;hb=HEAD

What happens if domain is sold and former owner won't cooperate with
issuing new voucher or hand over private key for former server cert? How
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean-Marc Desperrier | 8 Feb 20:58
Picon
Gravatar

Google about to fix the CRL download mechanism in Chrome

Hi,

Google just published the changes they are about to do in the revocation 
checking in Chrome :
http://www.imperialviolet.org/2012/02/05/crlsets.html

In my opinion, maybe somewhat opposite to the way they describe it, 
fundamentally they are not *at* *all* changing the standard PKI method 
of revocation check.

They are instead just solving a number of flaws in the way the CRL 
revocation information is fetched by browser, therefore implementing a 
new CRL fetching method that *works*, replacing the current *broken* one.

To work properly, CRL fetching must be done in advance of accessing the 
site. This never worked properly when you had to individually, locally 
determine the list of CRL to download.
Therefore establishing  centrally the list of public CRL to download, 
and pushing the result to browsers *is* the proper solution.

The other trouble with CRL in that in practice the only solution that's 
available is to download complete CRL, that include all revocation 
reason, resulting in awful bandwidth requirements.

Whereas the optimal solution would be to download each day a delta CRL, 
with only the difference with the previous day, and containing only the 
revocation reasons you *really* care about (key compromise).

By centrally converting the CRL format to a proprietary optimized format 
that contains only that, they can do it, without implementing in the
(Continue reading)

Permalink | Reply | 1 comment |

Gmane