2 added 122 characters in body
source | link

I have the feeling that you are trying to tackle the problem you have from the wrong end:

I always find it a pain to create a new key for development ...

I'm not sure what you are doing which causes so much pain, but if you are doing the same steps again and again it might be actually useful to find a way to automate these steps for yourself.

It actually seems more secure for me as a developer than creating a self-signed certificate using publicly available tools and having the key sitting around on my hard drive for my tools to use. If anyone got that, they could spoof any website for me because I have to trust it, right?

If I interpret this correctly you are creating a self-signed server certificate with basic constraints CA true (i.e. this certificate can be used to issue certificates). It is correct that this can be used to create more certificate and thus access to the certificate and its key can be used to man-in-the-middle all sites - provided that you've imported this certificate as trusted CA (certificate authority) instead of a trusted server certificate. Still, it meansNote that just adding an exception once the browser complains will not add this certificate as certificate authority.

It also would mean that the attacker needs to have access to your system in the first place - in which case it might do even more harm.

  Nevertheless, this particular problem can be easily mitigated:

  • Most (all?) browsers actually can import a self-signed server certificate which has basic constraints CA false. There are though tools which cannot deal with this and expect CA true on a self-signed certificate.
  • One could create a CA with its own private key, let it issue some leaf certificates (basic constraints CA false) with their ownanother private key and then throw the private key of the CA away. The CA can still be imported as trusted into the browser so that all certificates issued by this CA will be trusted too. Since the private key of the CA is deleted one cannot create more certificates though.

fakesite.com would send all subdomains to one page on the main website which would explain what it was for. The actual certificate and private key would be made available elsewhere such as in a github repository.

It is not a good idea to use a publicly available domain for this. The problem is that it is insecure by default, i.e. the browser will resolve the domain and try to connect to it and man in the middle attacks to the domain will not be detected since everybody knows the private key to mount invisible attacks. And then the attacker could do the attacks you've already described and maybe more.

Fortunately the public CA which has issued the certificate would revoke the certificate anyway if the private key gets known publicly anywayand thus this idea would not work (provided that the browsers check for revocation - which many don't or don't do properly).

But the general idea could be modified to be safer. If one simply uses a domain which will never exist publicly, a browser can only connect to the domain if the system is specifically setup for this. RFC 2606 defines some top level domains which might be used for this, i.e. .example, .test, .invalid and .localhost. When using any of these top level domains an attacker could only harm developer systems which are specifically setup to resolve such domains and which have explicitly imported this certificate as a trusted server certificate, instead of being able to harm arbitrary systems.

I have the feeling that you are trying to tackle the problem you have from the wrong end:

I always find it a pain to create a new key for development ...

I'm not sure what you are doing which causes so much pain, but if you are doing the same steps again and again it might be actually useful to find a way to automate these steps for yourself.

It actually seems more secure for me as a developer than creating a self-signed certificate using publicly available tools and having the key sitting around on my hard drive for my tools to use. If anyone got that, they could spoof any website for me because I have to trust it, right?

If I interpret this correctly you are creating a self-signed server certificate with basic constraints CA true (i.e. this certificate can be used to issue certificates). It is correct that this can be used to create more certificate and thus access to the certificate and its key can be used to man-in-the-middle all sites - provided that you've imported this certificate as trusted CA (certificate authority) instead of a trusted server certificate. Still, it means that the attacker needs to have access to your system in the first place - in which case it might do even more harm.

  Nevertheless, this particular problem can be easily mitigated:

  • Most (all?) browsers actually can import a self-signed server certificate which has basic constraints CA false. There are though tools which cannot deal with this and expect CA true on a self-signed certificate.
  • One could create a CA with its own private key, let it issue some leaf certificates (basic constraints CA false) with their own private key and then throw the private key of the CA away. The CA can still be imported as trusted into the browser so that all certificates issued by this CA will be trusted too. Since the private key of the CA is deleted one cannot create more certificates though.

fakesite.com would send all subdomains to one page on the main website which would explain what it was for. The actual certificate and private key would be made available elsewhere such as in a github repository.

It is not a good idea to use a publicly available domain for this. The problem is that it is insecure by default, i.e. the browser will resolve the domain and try to connect to it and man in the middle attacks to the domain will not be detected since everybody knows the private key to mount invisible attacks.

Fortunately the public CA which has issued the certificate would revoke the certificate if the private key gets known publicly anyway.

But the general idea could be modified to be safer. If one simply uses a domain which will never exist publicly, a browser can only connect to the domain if the system is specifically setup for this. RFC 2606 defines some top level domains which might be used for this, i.e. .example, .test, .invalid and .localhost. When using any of these top level domains an attacker could only harm developer systems which are specifically setup to resolve such domains instead of being able to harm arbitrary systems.

I have the feeling that you are trying to tackle the problem you have from the wrong end:

I always find it a pain to create a new key for development ...

I'm not sure what you are doing which causes so much pain, but if you are doing the same steps again and again it might be actually useful to find a way to automate these steps for yourself.

It actually seems more secure for me as a developer than creating a self-signed certificate using publicly available tools and having the key sitting around on my hard drive for my tools to use. If anyone got that, they could spoof any website for me because I have to trust it, right?

If I interpret this correctly you are creating a self-signed server certificate with basic constraints CA true (i.e. this certificate can be used to issue certificates). It is correct that this can be used to create more certificate and thus access to the certificate and its key can be used to man-in-the-middle all sites - provided that you've imported this certificate as trusted CA (certificate authority) instead of a trusted server certificate. Note that just adding an exception once the browser complains will not add this certificate as certificate authority.

It also would mean that the attacker needs to have access to your system in the first place - in which case it might do even more harm. Nevertheless, this particular problem can be easily mitigated:

  • Most (all?) browsers actually can import a self-signed server certificate which has basic constraints CA false. There are though tools which cannot deal with this and expect CA true on a self-signed certificate.
  • One could create a CA with its own private key, let it issue some leaf certificates (basic constraints CA false) with another private key and then throw the private key of the CA away. The CA can still be imported as trusted into the browser so that all certificates issued by this CA will be trusted too. Since the private key of the CA is deleted one cannot create more certificates though.

fakesite.com would send all subdomains to one page on the main website which would explain what it was for. The actual certificate and private key would be made available elsewhere such as in a github repository.

It is not a good idea to use a publicly available domain for this. The problem is that it is insecure by default, i.e. the browser will resolve the domain and try to connect to it and man in the middle attacks to the domain will not be detected since everybody knows the private key to mount invisible attacks. And then the attacker could do the attacks you've already described and maybe more.

Fortunately the public CA which has issued the certificate would revoke the certificate anyway if the private key gets known publicly and thus this idea would not work (provided that the browsers check for revocation - which many don't or don't do properly).

But the general idea could be modified to be safer. If one simply uses a domain which will never exist publicly, a browser can only connect to the domain if the system is specifically setup for this. RFC 2606 defines some top level domains which might be used for this, i.e. .example, .test, .invalid and .localhost. When using any of these top level domains an attacker could only harm developer systems which are specifically setup to resolve such domains and which have explicitly imported this certificate as a trusted server certificate, instead of being able to harm arbitrary systems.

1
source | link

I have the feeling that you are trying to tackle the problem you have from the wrong end:

I always find it a pain to create a new key for development ...

I'm not sure what you are doing which causes so much pain, but if you are doing the same steps again and again it might be actually useful to find a way to automate these steps for yourself.

It actually seems more secure for me as a developer than creating a self-signed certificate using publicly available tools and having the key sitting around on my hard drive for my tools to use. If anyone got that, they could spoof any website for me because I have to trust it, right?

If I interpret this correctly you are creating a self-signed server certificate with basic constraints CA true (i.e. this certificate can be used to issue certificates). It is correct that this can be used to create more certificate and thus access to the certificate and its key can be used to man-in-the-middle all sites - provided that you've imported this certificate as trusted CA (certificate authority) instead of a trusted server certificate. Still, it means that the attacker needs to have access to your system in the first place - in which case it might do even more harm.

Nevertheless, this particular problem can be easily mitigated:

  • Most (all?) browsers actually can import a self-signed server certificate which has basic constraints CA false. There are though tools which cannot deal with this and expect CA true on a self-signed certificate.
  • One could create a CA with its own private key, let it issue some leaf certificates (basic constraints CA false) with their own private key and then throw the private key of the CA away. The CA can still be imported as trusted into the browser so that all certificates issued by this CA will be trusted too. Since the private key of the CA is deleted one cannot create more certificates though.

fakesite.com would send all subdomains to one page on the main website which would explain what it was for. The actual certificate and private key would be made available elsewhere such as in a github repository.

It is not a good idea to use a publicly available domain for this. The problem is that it is insecure by default, i.e. the browser will resolve the domain and try to connect to it and man in the middle attacks to the domain will not be detected since everybody knows the private key to mount invisible attacks.

Fortunately the public CA which has issued the certificate would revoke the certificate if the private key gets known publicly anyway.

But the general idea could be modified to be safer. If one simply uses a domain which will never exist publicly, a browser can only connect to the domain if the system is specifically setup for this. RFC 2606 defines some top level domains which might be used for this, i.e. .example, .test, .invalid and .localhost. When using any of these top level domains an attacker could only harm developer systems which are specifically setup to resolve such domains instead of being able to harm arbitrary systems.