Indicate which DNS providers support DoT over port 443 #1178

Merged
nitrohorse merged 3 commits from indicate-443-port-for-dot-providers into master 2019-08-22 20:01:34 +00:00
nitrohorse commented 2019-08-18 05:14:19 +00:00 (Migrated from github.com)

Description

This PR adds a tooltip to the providers who support DoT over port 443 in addition to the expected port 853. This is an important indication because like DoH, DoT/443 makes eavesdropping more difficult for third parties and provides the benefit of not easily being blocked by firewalls compared to 853.

Resolves: #none

Check List

Code Repository (if applicable): N/A

<!-- PLEASE READ OUR [CONTRIBUTING GUIDELINES](https://github.com/privacytoolsIO/privacytools.io/blob/master/.github/CONTRIBUTING.md) BEFORE SUBMITTING --> ## Description This PR adds a tooltip to the providers who support DoT over port 443 in addition to the expected port 853. This is an important indication because like DoH, DoT/443 makes eavesdropping more difficult for third parties and provides the benefit of not easily being blocked by firewalls compared to 853. Resolves: #none #### Check List <!-- Please add an x in each box below, like so: [x] --> - [x] I have read and understand [CONTRIBUTING.md](https://github.com/privacytoolsIO/privacytools.io/blob/master/.github/CONTRIBUTING.md). - ~~[ ] I have listed the source code for this project in [source_code.md](https://github.com/privacytoolsIO/privacytools.io/blob/master/source_code.md).~~ - ~~[ ] This project is [free/libre software](https://www.wikipedia.org/wiki/Free_software).~~ - ~~[ ] This project has an [associated discussion](https://github.com/privacytoolsIO/privacytools.io/issues).~~ (via Wire chat) Code Repository (if applicable): N/A
blacklight447 (Migrated from github.com) reviewed 2019-08-18 05:14:19 +00:00
netlify[bot] commented 2019-08-18 05:14:57 +00:00 (Migrated from github.com)

Deploy preview for privacytools-io ready!

Built with commit 8c81461501

https://deploy-preview-1178--privacytools-io.netlify.com

Deploy preview for *privacytools-io* ready! Built with commit 8c8146150126c47442e4f6c9537dce13ba94483a https://deploy-preview-1178--privacytools-io.netlify.com
Mikaela (Migrated from github.com) reviewed 2019-08-18 08:19:37 +00:00
Mikaela (Migrated from github.com) left a comment

It's a good beginning, but:

  • https://deploy-preview-1178--privacytools-io.netlify.com/providers/dns/#icanndns -> I think the colour is too light or difficult to spot
  • I wish the sorting preferred DoT in port 443 over DoT in port 853 due to below
  • Could the terms be updated to clarify this? I am thinking that DoT should mention "...which is often blocked by restrictive firewalls, while 443 generally works everywhere"?
    • I started wondering about DPI that can distinguish SSH from https, but can it distinguish TLS encrypted traffic from other https traffic?
It's a good beginning, but: * https://deploy-preview-1178--privacytools-io.netlify.com/providers/dns/#icanndns -> I think the colour is too light or difficult to spot * I wish the sorting preferred DoT in port 443 over DoT in port 853 due to below * Could the terms be updated to clarify this? I am thinking that DoT should mention "...which is often blocked by restrictive firewalls, while 443 generally works everywhere"? * I started wondering about DPI that can distinguish SSH from https, but can it distinguish TLS encrypted traffic from other https traffic?
blacklight447 (Migrated from github.com) reviewed 2019-08-18 11:23:17 +00:00
nitrohorse commented 2019-08-18 19:09:53 +00:00 (Migrated from github.com)

Hmm, these are good points 🤔

I think the colour is too light or difficult to spot

Yeah that makes sense, what if I also bold the text instead of relying on just a color change? Will push an update to try it.

I wish the sorting preferred DoT in port 443 over DoT in port 853 due to below

Okay, I'll give those three providers' protocol field a custom value so they're grouped together while everything else sorts by length? I'll push an update for this.

Could the terms be updated to clarify this? I am thinking that DoT should mention "...which is often blocked by restrictive firewalls, while 443 generally works everywhere"?

Good callout; will do 👍

I started wondering about DPI that can distinguish SSH from https, but can it distinguish TLS encrypted traffic from other https traffic?

That's a good question; from my understanding, couldn't your ISP distinguish TLS from HTTPS traffic based on traffic analysis + connection metadata?

The technique used to identify SSL clients is called SSL Client Fingerprinting. By looking at the various components of the ClientHello during the SSL handshake, we can take an educated guess of whether the SSL client is a browser or something else. -- https://security.stackexchange.com/questions/48786/identify-https-vs-application-ssl-traffic

Hmm, these are good points :thinking: > I think the colour is too light or difficult to spot Yeah that makes sense, what if I also bold the text instead of relying on just a color change? Will push an update to try it. > > I wish the sorting preferred DoT in port 443 over DoT in port 853 due to below > Okay, I'll give those three providers' protocol field a custom value so they're grouped together while everything else sorts by length? I'll push an update for this. > Could the terms be updated to clarify this? I am thinking that DoT should mention "...which is often blocked by restrictive firewalls, while 443 generally works everywhere"? Good callout; will do :+1: > > I started wondering about DPI that can distinguish SSH from https, but can it distinguish TLS encrypted traffic from other https traffic? That's a good question; from my understanding, couldn't your ISP distinguish TLS from HTTPS traffic based on traffic analysis + connection metadata? > The technique used to identify SSL clients is called SSL Client Fingerprinting. By looking at the various components of the ClientHello during the SSL handshake, we can take an educated guess of whether the SSL client is a browser or something else. -- https://security.stackexchange.com/questions/48786/identify-https-vs-application-ssl-traffic
Mikaela (Migrated from github.com) reviewed 2019-08-19 18:20:19 +00:00
Mikaela (Migrated from github.com) left a comment

Looks great 👍

Looks great :+1:

I wonder if green is the best color choice, does it imply that configuration is more secure than others? I'd probably prefer using text-info or maybe text-primary. Or even just black with bold text.

I wonder if green is the best color choice, does it imply that configuration is more secure than others? I'd probably prefer using `text-info` or maybe `text-primary`. Or even just black with bold text.
nitrohorse commented 2019-08-20 04:34:19 +00:00 (Migrated from github.com)

I wonder if green is the best color choice, does it imply that configuration is more secure than others? I'd probably prefer using text-info or maybe text-primary. Or even just black with bold text.

I've removed the color; you're right; DoT/443 isn't necessarily more secure from my understanding, but doesn't stand out as much. In other words, it's more difficult to eavesdrop on and block.

@Mikaela this makes me think our description for DoT/443 in the terms could mention that eavesdropping is more difficult. Currently it says:

DNS-over-TLS (DoT) - A security protocol for encrypted DNS on a dedicated port 853. Some providers support port 443 which generally works everywhere while port 853 is often blocked by restrictive firewalls.

> I wonder if green is the best color choice, does it imply that configuration is more secure than others? I'd probably prefer using `text-info` or maybe `text-primary`. Or even just black with bold text. I've removed the color; you're right; DoT/443 isn't necessarily more secure from my understanding, but doesn't stand out as much. In other words, it's more difficult to eavesdrop on and block. @Mikaela this makes me think our description for DoT/443 in the terms could mention that eavesdropping is more difficult. Currently it says: > DNS-over-TLS (DoT) - A security protocol for encrypted DNS on a dedicated port 853. Some providers support port 443 which generally works everywhere while port 853 is often blocked by restrictive firewalls.
Mikaela commented 2019-08-20 09:13:38 +00:00 (Migrated from github.com)

In other words, it's more difficult to eavesdrop on and block.

@Mikaela this makes me think our description for DoT/443 in the terms could mention that eavesdropping is more difficult. Currently it says:

What do you mean by eavesdropping? The queries are encrypted from you to the DNS server and no one else can read them.

> In other words, it's more difficult to eavesdrop on and block. > > @Mikaela this makes me think our description for DoT/443 in the terms could mention that eavesdropping is more difficult. Currently it says: What do you mean by eavesdropping? The queries are encrypted from you to the DNS server and no one else can read them.
Mikaela (Migrated from github.com) approved these changes 2019-08-20 09:15:25 +00:00
nitrohorse commented 2019-08-20 14:31:22 +00:00 (Migrated from github.com)

@Mikaela ah sorry, by eavesdropping, I mean DoT/443 could potentially be more difficult for your ISP/3rd parties to analyze and detect than DoT/853, yeah?

@Mikaela ah sorry, by eavesdropping, I mean DoT/443 could potentially be more difficult for your ISP/3rd parties to _analyze_ and _detect_ than DoT/853, yeah?
Mikaela commented 2019-08-20 14:48:20 +00:00 (Migrated from github.com)

by eavesdropping, I mean DoT/443 could potentially be more difficult for your ISP/3rd parties to analyze and detect than DoT/853, yeah?

Possibly yes, but I am not comfortable making that claim personally until someone wiser tells me so

> by eavesdropping, I mean DoT/443 could potentially be more difficult for your ISP/3rd parties to analyze and detect than DoT/853, yeah? Possibly yes, but I am not comfortable making that claim personally until someone wiser tells me so
Mikaela commented 2019-08-22 19:45:31 +00:00 (Migrated from github.com)

As I went jabbering about this on the forum could we have a review and merge? :)

As I went jabbering about this [on the forum](https://forum.privacytools.io/t/dns-over-https-doh-vs-dns-over-tls-dot-where-do-you-stand/1433?u=mikaela) could we have a review and merge? :)
jonah approved these changes 2019-08-22 19:51:24 +00:00
dawidpotocki (Migrated from github.com) approved these changes 2019-08-22 19:52:33 +00:00
dawidpotocki (Migrated from github.com) reviewed 2019-08-22 20:00:30 +00:00
dawidpotocki (Migrated from github.com) commented 2019-08-22 20:00:03 +00:00

What about adding question mark next do DoT?
It is hard to tell that there is hidden info.

What about adding question mark next do DoT? It is hard to tell that there is hidden info.
This repo is archived. You cannot comment on pull requests.
No Milestone
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#1178
No description provided.