0

I read in the following passage in this DigitalOcean article, concerning HTTP/2:

Even though HTTP/2 does not require encryption, developers of two most popular browsers, Google Chrome and Mozilla Firefox, stated that for the security reasons they will support HTTP/2 only for HTTPS connections. Hence, if you decide to set up servers with HTTP/2 support, you must also secure them with HTTPS.

Okay, let's say I install OpenSSL on port 443 and use TLS to wrap each packet with an encryption wrapper.

Will I still have HTTPS if I didn't setup an SSL certificate for each domain and associated it with OpenSSL? and if I will, will this be valid in Chrome/Firefox?

1 Answers1

0

I feel like a primer on how TLS works might answer some of your questions. We have a canonical question here for that:

How does SSL/TLS work?

The part that's relevant for your question is that in order to do TLS, the server must have an encryption private key.

This key is private, meaning that no copies of the key should exist anywhere else, so we can use it (and the corresponding public key) to uniquely identify the server.

Consider a browser visiting your site for the first time - how does it know that it's talking to the real yourdomain.com and not an attacker trying to spoof your site?

That's where certificates come in: a Certificate Authority issues a certificate to say "we have verified that this public key does in fact belong to the legitimate owners of mydomain.com. Browsers take this as proof that they are talking to the authentic server for that URL / domain.

Browsers require every server to present a valid certificate matching the domain requested for each TLS connection, and (in theory at least) each server should be using a unique keypair and certificate.

TLS is a bit tricky to wrap your head around, and getting a cert from a CA and installing it properly can be a bit fiddly, but if you follow your guide you should have it up and running in a day or two.

Mike Ounsworth
  • 58,107
  • 21
  • 154
  • 209
  • Thx Mike. I think I still mis this: If the certificate prevents spoofing, why is it needed to encrypt the packets with TLS? I mean, one could send and receive data encrypted, whether the site site is spoofed or not (example.com or example1.com that look 99% like the former). Both example.com and example1.com could have their packets wrapped and the user could fill in sensitive data into both of them. So I miss either how certification is necessitated for the technical process of encrypting, and also, how it actually prevents spoofing (not our topic but your might want to elaborate a bit). –  Aug 05 '17 at 04:02
  • I didn't "spoofing" in the link. –  Aug 05 '17 at 04:03
  • @Benia You are right that encryption and anti-spoofing (done by digital signatures) are completely independent and not necessary for each other. You could design your own protocol in which you can do one without the other, but the people who designed TLS decided that you always need both. There was no technical reason why it *needed* to be this way, only that they wanted "your connection is secure" to mean that you are talking to the correct server, *and* that nobody can read / modify your traffic. – Mike Ounsworth Aug 05 '17 at 04:07
  • That said, encryption without authentication isn't really very useful. Think of it this way: you have a secret that you put in a safe, but if you're willing to tell the lock combination to anybody who asks, then it's not really a secret is it? – Mike Ounsworth Aug 05 '17 at 04:11
  • Of course it isn't, but I still miss this about spoofing --- What does spoofing has to change anything?... If someone makes copy of example.com in example.net, how can a user that register tell the difference? How the fact I have certificate in example.com change anything in example.net? It's basically two totally different sites... You might wanna edit just to clarify that? This is my main difficulty (I already know the issue of combining a public key and private key from OpenSSH). –  Aug 05 '17 at 12:36
  • Ah, I understand the question. As far as the user UI is concerned the "spoofing" has to do with the URL bar and whether it shows up with a nice green lock or not. – Mike Ounsworth Aug 05 '17 at 16:31
  • But the spoofer could make it have this Green block, I assume. –  Aug 05 '17 at 17:53
  • @Benia I think you should go read how TLS works. **The entire reason certificates exist is to prevent spoofers from getting the green lock**. (well, if you're trying to go to `google.com` but type instead `googe.com`, then the browser will happily fetch `googe.com`, green lock and all, but no spoofer will ever be able to get a green lock for `google.com`. At the end of the day, it's up to the user to check that the URL is correct. No amount of software can fix that -- software can't read you mind about what site you're trying to reach.) – Mike Ounsworth Aug 05 '17 at 18:01
  • 1
    There are also different "levels" of green lock. It's becoming more and more common to see a company name ([Microsolf, inc], or [Bank Of America]) in the green lock. This is nearly impossible to spoof because in order to get that certificate, you need a signed letter from the CEO of the company. – Mike Ounsworth Aug 05 '17 at 18:09