HTTPS security (secrecy & authenticity)

Public forum Technical questions
1

TLS is the security layer that is used for HTTPS.

There are two different reasons to use HTTPS over HTTP:

  • Secrecy: Only you and the web page you visit know what you are browsing because the packets are encrypted
  • Authenticity: You have a guarantee that you are visiting the original web page, and not a fraudulent copy (man-in-the-middle attack)

The first one is not in doubt here, as long as everyone uses long enough strong keys (which is not always the case). Although none of the keys used is perfect, you are the only one responsible for the secrecy of your communications, and by using RSA keys of 4096 bits in your server we can assume that even the No Such Agency (NSA) is unlikely to decrypt it in many decades. If you want mathematically perfect encryption, it exists, although not many need it, and it is impractical for most internet uses. As a reference, though, there are some attempts to use it in internet communications: Jericho Comms.

Of course, 0-day attacks are still a security problem for everyone, and they are caused by bugs in the different software you use in your website, so they are inevitable because your website needs software to run. The NSA usually uses this kind of attacks to penetrate into really secure communications. The best prevention for this security problem is to run as few software as possible with the least number of features you can, and the most stable options for those few software you need. Isolating each service of your web is another good measure to prevent breaches from affecting all your services.

The big problem is instead in the authenticity of the web page. How do you guarantee that the web you are connecting to is not a hacker or the NSA impersonating the web you want? The answer is simple: you can’t.

Actual authenticity model

The actual model for HTTPS authenticity is based on the following:

A web page presents a certificate to your browser. That certificate will be signed by another certificate and the private key corresponding to that other certificate, forming a chain until you arrive to the last certificate in the chain, which is only signed by a private key. If the keys used are strong enough, we can consider the signing operation to be valid. However, as the last certificate in the chain is not signed by any certificate, you have no absolute proof of who signed it.

Those certificates are called root certificates, and they are emitted by big companies, most of them US based, called Certificate Authorities (CAs). You usually receive those certificates preinstalled in your web browser or your operating system.

Problem 1

There is a recursive problem in this model: You download the browser from an insecure channel, where an attacker might have added his certificate to the list of trusted certificates (browsers have hundreds or thousands of those, so one more will go unnoticed). Even if you download the browser using HTTPS or another “secure” internet channel, it all goes back to some moment in time where you downloaded the certificates or hashes or public keys for all that security.

Problem 2

There are thousands of CAs, and not all of them are equally secure. Given that all of them have the same power, hacking one of them breaks the whole chain of trust up to that point in time. If a hacker hacks into one of those, he has the ability to impersonate any site he wants, and insert its own certificate in your computer before he gets noticed.

Problem 3

These root CA companies are Too Big To Fail. What it means is that so many web sites depend on them on the internet (in some cases more than 10% of the internet), that if they would have to shut down because of a security threat, most of the internet would have to shut down. It would cost millions or even billions. For that reason, although the actual model is based on the fact that if a CA gets compromised, it should be immediately revoked to keep people safe, it is easier for them to keep that in secret so no one notices and they can just continue getting lots of money from their business.

Problem 4

All US based CAs are obliged to give control to the NSA when the NSA asks for it, and they are also obliged to keep it secret. This problem is most important to people like Snowden.

Solution

If you can guarantee that the channel of distribution of a root certificate is authentic (you don’t need it to be secret, only authentic), for example if you delivered it in person by hand, you can guarantee that all certificates signed by it will be equally authentic.

Of course, if you deliver a normal self-signed certificate to a friend, you could sign any certificate with it, even one for google.com. That is a problem because you could then impersonate any site in your friends browser. But luckily your friend doesn’t need to trust you. Instead, you can give your friend a self-limited certificate which can only certify a specific domain, for example alejandro-colomar.es. That way, his browser will only accept a certificate signed by your root certificate if it is for that domain.

Then your friend, if he needs to be 100% sure that the web page is yours and not a hacker’s copy, he has to disable all full-power not-limited certificates temporarily, and then his browser will show a green lock if and only if the web site is certified by your root certificate.

Problems of this solution

  • It’s impossible to distribute your root certificate by hand to everyone else in the world, so your site will only be 100% authentic (green lock) for those who receive it. For everyone else, your site will show a warning message that the site authenticity cannot be guaranteed. This is not really a problem: that lack of authenticity is already happening, only that you still see a green lock, which gives you a false sense of authenticity.

Usually, authenticity is not really needed: when you visit a web to search for some help about programming, or you want to play a game, or read a book, or listen to music, etc, you don’t really care about authenticity.

If you connect to a web, and you don’t enter or download some sensitive data, you can still connect without its certificate and still don’t care: the worst thing that could happen is a hacker showing you wrong information.

  • Implementing a Public Key Infrastructure (PKI) of your own requires a lot of knowledge, a lot of care, and keeping it updated.

Any failure to in implementing that PKI completely secure can undermine all its security, and most likely you wouldn’t even notice, which would be an even greater problem.

For that reason, it is likely to take years to implement it right. My objective with the SMR2: Decentralize the internet project is to make it open-source, so that it is possible to anyone to deploy his own PKI and server in a very short time, with little work.

Real threat

Hackers usually do what they do (attacks) either for money, for principles, or just for fun. With that in mind, it’s unlikely that they will attack you personally, so as long as you keep your security in the average or above, you can stay more or less secure.

However, state level organizations, especially from the USA and China, have a lot more resources and motivation than those hackers to attack individuals. They basically collect every communication, even encrypted (especially encrypted), and store it for when they need/can break it.

Of course, all this security on your own is not enough to stop the NSA or China from hacking you as an individual, because they have enough resources to break into almost any single system they want, but if everyone had this level of security, they wouldn’t be able to process all that amount of information; massive surveillance would have big trouble.

In the end this is all about freedom of speech, freedom of information & privacy of communications, which are every day in more danger.

Scaling up this solution

If everyone had their own PKI, you wouldn’t need to receive that list of official root certificates with your browser. You would just need the certificates of your friends, a certificate from the bank (for your online shopping), the state administration, and a few more high security ones, and you could do most of what you already do right now, and you would do it with even more security than you do now.

If some person’s (or your bank’s) CA would get compromised, they would immediately give you personally the new certificate, because there would be less incentive in not telling you.

State-level censorship and mass surveillance would suddenly shut down, or would have to find a new way to continue.

Big internet companies such as Facebook, Google, Twitter, etc, might face bankruptcy.

For reference, there are a few links about this problem:

1 Like
2

I would see this kind of thing used for data connections that have to be secure. (in a way i basicly use this for my own server SSH connection)

but I have some question about this for the whole internet. How would you mass distrobute these personal PKIs? say for youtube (where a lot of poeple do earn money) or small businesses that suddenly have to hand out PKIs to visit their online store? This would put a lot of power in larger platforms that offer “webshop” solutions. Such as Etsy for poeple filling a nich product. So what I would see happening is that companies start to distribute PKIs. Want to access youtube? don’t have to contact youtube, just contact us and we send you a key. google could fill that role nicely. Search our database for your favourite store! request a PKI and we ship it out to you.

How would that scenario be any diffrent then what we have now? We suddenly trust companies to send out the correct PKI without any issue. Plus it suddenly create massive walls with online communicates for new comers.

3

@Laurens

How would you mass distrobute these personal PKIs?

Saddly, you can’t. Maybe you can print the fingerprint or hash of your certificate in a card you give to your physical customers when they enter your shop.

say for youtube (where a lot of poeple do earn money)

YouTube users don’t (usually) need authenticity. You go there to enjoy music and videos. If you need some sensitive content from youtube, then you would have a problem, and maybe Youtube would start having something like applestores where they could give their certificates.

small businesses that suddenly have to hand out PKIs to visit their online store

Small businesses have it better in a sense, because they can see their clients personally (at least once). However, for small businesses that have a globally distributed set of clients (not local clients), this would be a big problem.

So what I would see happening is that companies start to distribute PKIs.

If you browse content that is not sensitive, you wouldn’t need it. If you do, you would have to be careful. You should trust the distributor as much as the server you want to access, which is not always possible. But at least you would know who you are really trusting.

Search our database for your favourite store! request a PKI and we ship it out to you.

You could use unauthenticated (but still secret) connections for stores for filling your basket, and then they would redirect you to an authenticated connection with your bank for the payment (getting a PKI from your bank is way more easy than getting the PKIs of all the stores out there), which is really the sensitive step.

4

Saddly, you can’t. Maybe you can print the fingerprint or hash of your certificate in a card you give to your physical customers when they enter your shop.

You could use unauthenticated (but still secret) connections for stores for filling your basket, and then they would redirect you to an authenticated connection with your bank for the payment (getting a PKI from your bank is way more easy than getting the PKIs of all the stores out there), which is really the sensitive step.

Lets take these two together because for me those two are a real issue. The sensative parts starts when someone fills in their personal details. I as webshop owner want the compelte webshop to have https encrypotion for that prupose. So that would also need that special PKI system? meaning i have to find a way to request and send PKis to every potentional customer? That is massive overhead, seeing as the avarage conversion rate is 4%, so for 4 sales i need to send 100 PKIs out in the world. Or will this be a two part system where you have some connections use this new system but the web as a general uses CA still because of the conviniance.

5

@Laurens

So that would also need that special PKI system? meaning i have to find a way to request and send PKis to every potential customer?

Yes (not request; only send).

That is massive overhead, seeing as the average conversion rate is 4%, so for 4 sales i need to send 100 PKIs out in the world.

Yes that is massive overhead, and a big brake to globalization. But you only need to send them the hash of the PKI certificate, which is usually a few dozens of characters, and can be printed in your company card (you can give hundreds of those like in the old days), and they can then download your CA certificate from the internet and check that the hash matches.

Or will this be a two part system where you have some connections use this new system but the web as a general uses CA still because of the convenience.

There are some options I can think of:

  • No coexistance: the world wide web just falls down into a hybrid between the dark web and the normal old web.

  • Manual coexistence: If you use two different browsers, you can have one of them with the preinstalled CAs, and understand that it is inherently insecure, and strip all the CAs from the other one (you could use the TOR browser for that) and only add to that one the CAs you received personally. This scenario might be a good transition.

However, this second scenario has some problems: if there are other more convenient (although more insecure) options, ignorant people will just not use it, and therefore the security of the whole will be compromised.

  • Browsers supported coexistence: browsers could develop a new feature, like a golden or silver lock, which would be enabled only for manually added CAs, and the green lock would be for standard preinstalled CAs. Then your bank might want to get the golden lock and give you their own CA certificates personally.
6

@Laurens @alejandro.colomar

It seems to me that a system where trusting a certificate depends on it being delivered to you in a transaction with inherently authentic transaction (eg. through handing over a certificate in person) will, though maybe most secure, never be practical enough.

Instead, authenticity might be established by validity through consensus, so that you change the problem from secure key exchange to the Byzantine General Problem (BGP).

The nice thing is that the BGP has been solved in bitcoin, mainly by securing its blockchain (which is basically a database) with unforgable proof of work.

As far as I can see, what remains then is having a bullet-proof way to:

  1. Association: Verifiably associating a private key with a domain name
  2. Scarcity: A rule to establish what the canonical key/domain association is.

The first item could be solved pretty easily by adding an transaction note.

Of course 2. is the same problem we had all along, but at least now the whole Root CA process becomes completely transparent, so that blacklisting of blockchain addresses would actually work towards securing the system: once a root address is compromised, you can simply invalidate the entire derived addresses forever.

Maybe this would actually give sufficient security.

1 Like
7

@thijs @Laurens

CAs work this way:

The person that runs a webserver has a private key, with which he creates a .csr file (certificate signing request), which is a file that contains some information about the server name and also contains the public key of the person who created it.

The CA receives that request (.csr) and signs it with its private key and its root certificate, producing a .cert (The certificate).

When you run a server, the server has the private key that was used to generate the request, and also the certificate (the certificate contains the public key), which is shown to users of the server. The users can check that the server corresponds to the certificate because they encrypt a simple message with the included public key and only the private key can decrypt it.

If and only if the CA is for some reason guaranteed to not be malicious, to perfectly analyze any requests before certifying them, be fully transparent, and impossible to be hacked, AND if all the CAs installed in your browser meet these same requirements (this is highly unlikely, but let’s assume that), then it is impossible for a hacker to impersonate your server.

The worst things that could happen are:

  • A hacker can block your request so that it never arrives to the CA.
  • A hacker can block the certificate from the CA so that it never arrives to your server.

Any of which would mean that your server could not run, but still no one else could run it.

Things that can go wrong:

  • A malicious person can try to certify a malicious copy of your server with his private key contacting another CA that doesn’t do as many checks, and that certificate will be equally valid. He can then impersonate your server with a green lock on the browser, which means that the browser recognizes the malicious server as a good one.

As I understand it, I think the blockchain could be used for certifying that the first person adding a name (some-server.com) is the owner of that name. And if someone just adds that same name to the blockchain later, it can just be ignored as a hacker. That would be a solution, if it’s possible.

The problem is that end user certificates are usually certified for something like 30 days and have to be renewed. The reason is that someone could hack into your server, and you then need to change your private key just in case, and start again the certification process.

For that reason you can’t just say that the first one is the good one and any later addition is just malicious, because it may be you that have been hacked and need to do a new certificate.

I still have some doubts about if it can be done, and how.

My concern:

Let’s say there are Google and Evil trying to register google.com in the block chain.

Each of them uploads to the blockchain a certificate created with their respective own private keys, and both try to register google.com. You can’t guarantee which of them will register it first; they are racing against each other.

Bob which doesn’t know Mr. Google personally, wants to connect to google.com, and looks up at the blockchain to download the certificate. But he finds two certificates that register google.com, and each certificate comes with a different public key. So how can Bob know which of the two certificates is the right one?

An option to use the blockchain would be that each person has their own root CA (which is not 30-day limited; the root CA is intended to be permanent), and therefore they need to keep that CA offline forever and kept with high security, and add their limited root CA to the blockchain. But if for some reason that root CA certificate ever needs to be changed, it would be a big problem, and probably some offline method should be used to let users know that change and which is the correct new one.

8

Deterministic private/public key creation from seed.

1 Like
9

P2P DNS:

https://ieeexplore.ieee.org/document/6785470

10

Name resolution on Tor network

https://www.icann.org/news/blog/the-dark-web-the-land-of-hidden-services

11

@thijs

I just found out this solution for a decentralized DNS based on bitcoin:

https://www.namecoin.org/dot-bit/

It also has an advantage over both the normal name domains, and the .onion domains: it supports both. alejandro-colomar.bit could be paired with either an IP or a .onion string.

1 Like
12

Will look into this later, especially interested in security/immutability of its chain