Understanding HTTPS

Hey @RoboRobok,

I don't have the answer for all of your questions, but maybe I can shed light on some of them.

1. Don't really know
2. Same
3. HTTPS ensures encryption. APIs that use HTTPS just want to make sure that the info they provide doesn't get sent through the web as plain-text.
4. We are paying for trust. A certificate ensures that the other side of the communication is actually the person/company/site they claim to be and not some scammer trying to fool you into believing so. (see https://www.instantssl.com/ssl-certificate-products/https.html )
5. Because an invalid certificate could be a sign that someone is actively trying to scam you, while no certificate at all just means that the other side doesn't care about security.
6. It actually is free now and people are working on making it the obvious standard: https://letsencrypt.org/
7. Don't know.

Also, I found this short video tutorial about SSL that could be of use to you: https://www.youtube.com/watch?v=iQsKdtjwtYI

Looks like we are on the same boat, I know just as much as you do. I've seen that video you suggested, it's pretty awful. It says about the algorithm in nerdy way, but doesn't answer the real-world questions, like the ones I asked.

Well, what you didn't know was that letsencrypt.org provides automated, free certificates for everyone now and does lobby work to make https the global standard.

Also, if you knew the answers to your questions, why did you ask the questions? :D

Anyway, I would like to see @JeffreyWay explain the details of HTTPS and certificates in a Laracasts series! :)

Oh yeah, HTTPS series would be a bomb.

I don't know some of the answers. The most interesting ones are the ones you replied "I don't know" too. It's hard to find the answers to them.

Question #3 still remains unanswered. It's obvious that they want to protect the plain text transfer, but the question is why? I understand that for sensitive data, but notifications? It doesn't even touch the server.

Question #4 is also unanswered. What is a scam here? Changed output? Phishing? I guess phishing uses own domain, so it can be certificated as well? Do these certificate givers take legal responsibility for their clients? In other words, if I get scammed in some way buy a website owner (let's say a store sent me brick instead of an iPhone), does legal responsibility lay on the certificate giver?

1. It is for both. If you use SSL certificates you are sure that you are connected with the servers of Company's X and all of the data that are transmitted are encrypted
2. Yes you are referring to Man in the Middle attacks. If the certificate is trusted, MAN attacks can not happen.
3. Think something like stripe, you exchange sensitive data, so these data should be encrypted in the network, that's why they force you to use https.

7 Implementations? You mean how to add an ssl to your webserver? There are plenty of tutorials online. Or some more technical approach?

The other questions have been answered by @ChristophHarms

Question #3 still remains unanswered. It's obvious that they want to protect the plain text transfer, but the question is why? I understand that for sensitive data, but notifications? It doesn't even touch the server.

I think that, now certificates are free for anyone, many people and companies share the opinion that you should just always encrypt your net traffic. Making encrypted transfer the standard weakens one attack vector: If some of the traffic is encrypted and some isn't, you can differentiate traffic that potentially includes sensitive data from traffic that doesn't. If everything is encrypted, it is much harder for attackers to tell which packages include sensitive data.

Question #4 is also unanswered. What is a scam here? Changed output? Phishing? I guess phishing uses own domain, so it can be certificated as well? Do these certificate givers take legal responsibility for their clients? In other words, if I get scammed in some way buy a website owner, like a store, does legal responsibility lay on the certificate giver?

One scenario is that someone would buy a domain that looks very much like another domain, like www.paypaI.com (the 'l' is actually a capital 'i'), then send fake mails to get you to input your paypal login data to their faked site. Since they won't be able to get a certificate for the real paypal.com, your browser would warn you about that.

Hmm, but the browser won't know it's pretending to be paypal.com. For the browser it's just paypai.com, isn't it?

Yes, the browser won't trigger an alert if the scammer uses Let's encrypt. Only if in some way, the browser knows that this is a phising attack.

On the 4th question, what do you mean by "notifications". Which notifications apis? Can you give us an example?

https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API

In Chrome 62 and newer you cannot request notification api at all unless the site is https:// secured. (see issue 779612) If you do have https on the site you should be able to use notifications and background push notifications.

Notification apis might exchange sensitive data like authentication headers.

The question is why you shouldm't implement SSL?

Some other platforms, like platforms that let you get the VAT of a specific country, (without forcing users to have a token, in order to access the platform), they do not transmit sensitive data, but again, they choose to use it because it is easy to install, more professional, and also provides that data are not tampered along the way. Why shouldn't they use SSL? It is compute cheap, and also does not cost that much.

I agree that the question would be "Why not use SSL?" :) I'm asking these questions for purely educational reasons.

Still not convinced about the notifications. They don't exchange anything, they just fire on the browser locally. Don't confuse them with push notifications.

Yup, sorry for that

It seems that features like Geolocation, AppCache, Notifications and more are not allowed for domains without SSL.

For the Notifications, I really do not know the reason. Is it a general move into marking HTTP as non secure and making web application owners to implement SSL? But, yes, using notifications in an HTTP website does not make it more unsafe that it really is.

Jonathan Kingston is "Front End Security for Firefox, working on HTTPS adoption, containers and content security" and he wrote this: "Going forward, Firefox will deprecate more APIs over insecure connections in an attempt to increase adoption of HTTPS and improve the safety of the internet as a whole.", link https://blog.mozilla.org/security/2018/02/12/restricting-appcache-secure-contexts/

So is it a general move, maybe yes?

Notifications are pushed from the server to your browser. If https was not used then you could get a notification from anybody's server and you would not know.

Notifications only 'fire on the browser locally' when they know something has changed on the server. The server pushes to the client for this to happen. otherwise your browser would be continually polling remote servers

@Snapey I have not used the notification api, but, I think that you can fire a notification to the browser even if the server has not pushed something to the client.

So in this scenario, using Notifications in an HTTP site does not make it more insecure than it really is.

Am i missing something here?

@Snapey you are totally wrong. This is NOT how Notifications API works.

There are two parts to it. The notifications API will open an alert in the native operating system. In most cases this notification is triggered by push API to a service worker registered in your browser.

Yes, you can have local only notifications, but what practical use are they really?

You are confusing Push API with Notification API. Notification is just a local bubble, how you create it is another story.

There are use cases for local notifications as well, think about a timer or reminder.

If a website isn't secured by HTTPS, it is vulnerable to man-in-the-middle attacks. That means the page you requested from an unsecured server may have been modified by a third party.

This third party may have modified the javascript code to display arbitrary system notifications, or at the very least modified the content of existing notifications.

You can find out more about Chromium's decision to restrict notifications to secured domains by following the link to the chromium bug from the MDN article you linked, and then the links in the second comment: https://bugs.chromium.org/p/chromium/issues/detail?id=779612#c2

If a website isn't secured by HTTPS, it is vulnerable to man-in-the-middle attacks.

... and eavesdropping (listening to the conversation)

@Snapey True. My post was entirely in regards to why allowing system notifications from unsecured domains is a bad idea, not about HTTPS in general. Should have made that clearer.