Hosts are fetched via HTTP

[savchenko]

> python updateHostsFile.py -a -r
Updating source yoyo.org from http://pgl.yoyo.org/...

Should we switch to HTTPS-only?

[FadeMind]

See: https://github.com/StevenBlack/hosts/pull/59 BUT IDK how yoyo.org SSL looking here...

[Laicure]

I think this topic solely depends on the sources if they use https, ftp, or whatever protocol as long as they provide the list so I think no issues here at all.

[StevenBlack]

@asvc thank you!

@FadeMind @Laicure with b1f2c3e I just made yoyo.org use https as this appears to work for me on OS X El Capitan.

Do either of you get certificate warnings for yoyo now?

Something in me wants to do the Simplest Thing That Could Possibly Work and that would be http. Because certs expire, and many other ways that cert issues can arise.

[FadeMind]

@StevenBlack yoyo.org via HTTPS working fine.

[Laicure]

Oh I see... /hmm So I think no data source cert/etc issues here on my side (Windows user). Thanks ;)

[skwerlman]

yoyo.org failing to download over https (i can still see it in browser, but it wont d/l from script)

on win10

[StevenBlack]

Works fine here: https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&mimetype=plaintext&useip=0.0.0.0

[benlowry]

@StevenBlack even though http is more likely to work each provides an opportunity for someone to inject a list of servers to block to aide an attack.... I think the default block lists should be HTTPS only.

[StevenBlack]

Thanks for your input on this Ben @benlowry.

Considering the extensibility of the hosts amalgamation, it's probably not realistic to force HTTPS without dealing with the opposite problem: people asking why force HTTPS when this or that particular source is great but is only available with HTTP.

But I totally understand what you're saying.

If someone cares to make a PR with a flag to force HTTPS, which we could make the default, and deal with both HTTP and HTTPS cases including error handling and documentation updates, well, I'd certainly entertain it.

[benlowry]

It should be force-http because that is where the danger lies.

This might be solvable by contacting the last defaults (I think only 2 exc. malwarebytes that I saw the other day has HTTPS) and asking if they'd provide a HTTPS version. I wrote the someonewhocares.org email address on Monday to suggest some free options they might use - https://letsencrypt.org/ for free SSL, https://www.cloudflare.com/ over their website, a github repo/gist etc. I'll dig into the other one and see if I can contact someone there too.

It's probably possible to replicate the lists in a git repo too and automatically keep them in sync as well. That would start with a potentially compromised list but every change would be traceable and people downloading that copy could be sure they are not receiving something that has been tampered with since.

[benlowry]

BTW @StevenBlack you might like how I have used your project - I used it to supplement a DNS server called Pi-hole that blocks ads and includes an admin interface and browser extensions, and I added the ability to use custom domains on your network.
This lets the blocking occur network-wide -

https://github.com/benlowry/pihole-extended-hosts

[StevenBlack]

Hey Ben @benlowry that's excellent!

Keep up the good fight! :-)

[benlowry]

The 'someonewhocares.org' person wrote me back and said he will look into providing a HTTPS version.

[StevenBlack]

This is great Brn @benlowry. Thanks!