-5

I got fun idea how to increase the security of the SSL (TLS) for websites. However I think there is no support for it in the browsers, so I thought I could add it eventually, but have no idea if it's supported.

Currently SSL works the way that there is always some English language country based company issuing certs based on their root key. Now this is all in the control of the goverment, because they can gain access to these keys upon request, and they have agreements to do it. However, for business this is not good enough, definitely.

So the thing is now to simply use double or more SSL connection one wrapping each other, and you would use two or more certificates, one issue by UK and one by China.

By having the public part of root keys from China and UK and do double encryption would make it unbreakable for both US and China.

Since Chinese root keys are included in Firefox, the only thing missing here is support for double-encryption.

This is seriously good model, because:

  • All user browsers have two public parts of public key
  • There is no way, that Chinese and US/UK would ever share their secret keys

This can be done by using open source browser like Firefox. It simply works the way, that connection is encrypted twice.

Just the domain negotiation is difficult. Either using two certs for a same domain, or using two domains, or using name similarity, or maybe sign the sub-domain in the name, and combine into two certs. Chaining with DNSSEC, or just same names, would be enough for example to establish communication between two parties, e.g. between UK and China.

UPDATE: It seems that the Chinese cert in FireFox is not secure, therefore there are no other certs or countries which could deliver this. But if the Chinese key is secure, simply be negotiating the domain, one could have a seriously encrypted connection and be government-proof, but if the all keys are shared, I'm left only with self-signed certs.

Seriously, maybe using self-signed cert is really more secure for a long-term customer, than actually government-controlled one? So maybe following scenario: "Please install our cert if you are paranoid about government". So this should be good as VPN. For doing business, like email, companies would have to exchange the certs, in order to achieve this level of security. So just an SMTP hub would be secure like this if done properly, if the customers would install the cert, and upload theirs, they could securely communicate with each other.

Therefore, the official, government-controlled certs are no use for secure communication, and it's better to use self-signed ones, and the certs can be downloaded and installed no problem via the browser. No encryption is required to transmit the public part (the root public key), and after confirmation of the known hashkey / picture, you can browse resource. The only thing is to do it properly, like first to install certificate, and then visit the website, and the cert would be fully valid. So you can approach the problem with private PKI instead relaying on the official and this is hopefully fully legal.

3
  • what's to stop the two certs being US and UK? And if one is MITM attack where country government generates a valid cert with there own trusted ca which is what I think you are trying to actually solve, why can't they pick an ally to do the second cert, or just do one layer to pass it on?
    – ewanm89
    Jul 15, 2012 at 14:11
  • Oh, and the Chinese and UK do do some sharing... After all Hong Kong is a Chinese protectorate but was under British governorship 'till 1998
    – ewanm89
    Jul 15, 2012 at 14:13
  • 4
    Andrew - comments are for requesting clarification, not for opinions, stating your thoughts etc. For discussions you're encouraged to pop over to chat in the DMZ.
    – Rory Alsop
    Jul 15, 2012 at 15:16

4 Answers 4

12

Currently SSL works the way that there is always some English language country based company issuing certs based on their root key. Now this is all in the control of the goverment, because they can gain access to these keys upon request, and they have agreements to do it. However, for business this is not good enough, definitely.

You're completely misunderstanding the way SSL/TLS and certificates work.

When you get a certificate for your server, you ask a CA to issue it based on the CSR (or equivalent) you send when applying for this certificate. The CSR contains the public key for your certificate. It does not contain the private key, which you should keep private (and install only on your server).

Even if a government has access to the CA's key, they won't have access to your server's private key. What someone in control of the CA can do is to issue spoof certificates that will be recognised by the clients that trust that CA.

This is indeed a problem if they are in a position to perform a MITM attack. However, having multiple layers of TLS encryption doesn't really add much. The real problem in this case is that the client trusts a CA (or certificates) it shouldn't trust in the scenario you're envisaging. If this is the case, and if you want to be more selective, remove the CAs you don't trust from your browser and pin down the exceptions for the certificates you know are correct (possibly based on the valid of the actual server's public key, which you know by some other means).

(In addition, DNSSEC would suffer from similar problems, since it also relies on trust anchors. If I'm not mistaken, it's also ultimately run by Verisign for .coms.)

2

This question is pretty far afield from how SSL actually works.

First - after the SSL handshake, the remainder of the communication is based upon a mutually negotiated symmetric key. How that key is negotiated is quite configurable - and both the server and the client can already be configured to limit options such that they meet the security requirements of the two parties trying to communicate. Running a second SSL session nested inside the first won't add anything as you'll mostly just have the two sides agreeing on a second shared secret. Worst case - highly dependant on encryption algorithms - is that your communication will unintentionally expose elements of the communication that you did not intend as the protocol simply wasn't designed to work this way.

Secondly - the statement:

Currently SSL works the way that there is always some English language country based company issuing certs based on their root key. Now this is all in the control of the goverment, because they can gain access to these keys upon request, and they have agreements to do it. However, for business this is not good enough, definitely.

Nope - not at all. Anyone can run their own root CA and intermediate CAs and issue their own certificate. It just takes money and time. Many, many private groups do this and most big companies (US or otherwise) who feel a need to mitigate risks coming from the lack of control of the root and intermediate CA key pairs will do this. I used to work in a CA vendor that sold CA products and helped customers design exactly this.

For groups that own their own PKI infrastructures and want to control communications further - there is no reason they can't reconfigure the trusted certificate store held in any major browser. The default list of trusted CAs that comes in IE, Firefox, Chrome, etc - is just that - a default. Anyone with the proper permissions can modify the store, removing any root or intermediate CA from the list and adding any custom-made certificate.

If a company has enough money (and if they run their own PKI infrastructure, this is a drop in the bucket) - they can create a default allowed browser image for any and all browsers and install that on company issued machines. Between the PKI infrastructure and the custom image, they will have an infrastructure that can operate completely independently from any external certificate seller.

I think this question is trying to solve a problem that never really existed - independently run browsers and PKI infrastructures have been in existence for over 20 years. Any business I've ever met with massive security risk relating to transaction integrity and confidentiality uses this and more to protect critical communications - they just don't need to make any of it publicly available.

1

Most of what you seem to believe about encryption, private keys and certificate is wrong, but IMO here is the most problematic part of your question (emphasis mine):

Now this is all in the control of the goverment, because they can gain access to these keys upon request, and they have agreements to do it. However, for business this is not good enough, definitely.

So you are afraid of governmental interference into encrypted communications, and want to do business? It means that you assume that the government might unduly interfere with your business communications.

If you cannot accept "interference" by either your government, or the government of your business partners, than the inevitable conclusion is that you cannot do business in this jurisdiction at all.

You have to move to a State where government interference in business is effectively (not just theoretically) limited by laws, and where the law is "safe enough" for your business.

Your business partners also live in some jurisdiction, and they could be forced by law to disclose to a judge the content of your encrypted communication with them: the whole point of TLS is that someone, somewhere can decrypt a message stream. It does not matter if you do TLS in TLS in TLS in TLS in TLS. Someone, somewhere, is listening to you over TLS. And that someone could have an agreement with its government to disclose that information.

0

From your second paragraph, you give the impression that you are overly paranoid. What makes you think that the Chinese-based root CA's will not hand over the certificates if the Chinese government request them? What makes you think the governments of different countries would not cooperate if your activities have international repercussions?

Your proposed solution is plausible in theory, but it is a lot of extra work for a pretty much unfounded fear. Support has to be built into many different stuff - browsers, servers etc.

Having two certificates would mean an entire additional set of stuff to take care of. What happens if the certs were compromised by an attacker? It would mean an extra set of certificates to revoke.

It really seems to me like you are grasping at nothing, trying to solve a pretty much non-existent problem.

1
  • 2
    "Having two certificates would mean an entire additional set of stuff to take care of." Obviously, it doubles the cost of obtaining and managing one certificate. What else? "Support has to be built into many different stuff - browsers, servers etc." The same code is used to check two certificate instead of one, and an additional check is done that the issuer is not the same. What else? "It really seems to me like you are grasping at nothing, trying to solve a pretty much non-existent problem." The rogue CA threat is very serious. Have you seen Diginotar? or COMODO (2 events)?
    – curiousguy
    Jul 16, 2012 at 7:49

Not the answer you're looking for? Browse other questions tagged .