Don’t trust publisher payment information over HTTP

[da2x]

Too tempting for public access points, caches, proxies, ISPs, malicious software, attackers, and myself to intercept HTTP requests to /tipsy.txt and insert their own payment information. The same goes for payment information extracted from pages.

I’ll submit a patch with the following logic change:

• Only read on-page payment details over HTTPS
• If HTTP page or no on-page payment details, then try to load /tipsy.txt over HTTPS.

This will allow publishers who for technical reasons still stick with HTTP for their main page to still supply payment information for Tipsy over HTTPS.

Browsers will begin marking websites loaded over HTTP as insecure later this year, so this policy is just keeping up with the times.

[tbranyen]

Is this to help mitigate MITM attempts?

[da2x]

Indeed. “public access points, caches, proxies, ISPs, malicious software, attackers” all qualify as men/women/persons/services in the middle.

[karger]

My only concern here is novices who haven't implemented https for their sites. Is there a way we can let them use http without compromising anyone else's tipsy security? Possibly not; obvious schemes don't work. For example, if I try https first and failover to http, then the MITM can just block the https connection to trick me.

[schilippe]

Given that Chrome is basically going to require HTTPS pretty soon I think novices will become familiar with it.

…

On Feb 15, 2017 10:52 PM, "David Karger" ***@***.***> wrote: My only concern here is novices who haven't implemented https for their sites. Is there a way we can let them use http without compromising anyone else's tipsy security? Possibly not; obvious schemes don't work. For example, if I try https first and failover to http, then the MITM can just block the https connection to trick me. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#104 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD5VYELzgJVIQKLbwpSwikNUe5vKZZUKks5rc8ftgaJpZM4MCVoy> .

[da2x]

there a way we can let them use http without compromising anyone else's tipsy security?

Setup a central register and curate a verified list. Painful, time-consuming, and undesirable.

Total novices host with Blogger, GitHub, WordPress, Squarespace, etc. These already provide HTTPS by default for their users.

HTTP-only origins already have limited access to modern browser APIs.

As I said, http will be marked as insecure in leading browsers later this year. (Actually, the first start at the end of the month!) Plain-text HTTP is taking it’s dying breaths.

[da2x]

… which reminds me that the project website is HTTP-only. 👎

[karger]

That's because its an insurmountable challenge for us novices to get an https certificate for our site ;)

…

On 2/15/2017 11:06 PM, Daniel Aleksandersen wrote: … which reminds me that the project website is HTTP-only. 👎 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#104 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABFpXo05z-h0QxLrqnPI6CJqWiQS82zQks5rc8s-gaJpZM4MCVoy>.

[tbranyen]

@karger I set up https://letsencrypt.org/ (free and open certificates) recently and it's been working well. used certbot which is a CLI tool that verifies your domain and issues the certificate. you can set it up to run on a schedule with cron as well (although I used systemd on my server). I can try and get a list of commands together to run to set this up, or help someone else who has access.

[karger]

It took a while but thanks to netlify I've been able to move http://tipsy.news/ to support https://tipsy.news/ as well.