Deploying HTTPS correctly, part 2
Is this edit really necessary? It seems unnecessarily negative in tone given that this is more of a how-to article than a pure rant. It's the kind of issue that should be taken up directly with EFF anyway.
I have no conflict of interest with EFF, unless you count the fact that a few of my HTTPS Everywhere ruleset submissions have been accepted. Eighty5cacao 09:42, 26 June 2012 (MST)
- The whole second paragraph is a rant about my frustration that it'll be another 22 months before SNI is widely deployable. Is there a nicer way to communicate 1. the existence of HTTPS Everywhere and 2. the lack of guidance in the HTTPS Everywhere documentation on how to work around the lack of SNI? I took it up with EFF earlier in June, and the reply was "I will forward your email to our team". --Tepples 10:15, 26 June 2012 (MST)
- I'm still thinking about it. I know similar articles exist elsewhere, but that's moot if your purpose is to "promote" HTTPS Everywhere. I'd need a while to prepare a more thorough reply. Eighty5cacao 10:01, 28 June 2012 (MST)
- The moral of part 1 is that a lot of web applications are bound by database IOPS or network bandwidth, not CPU time, and one can make up for the connection overhead of HTTPS by reorganizing a web application to make fewer round trips. But what I want to say in this paragraph is that 1. there is something called HTTPS Everywhere that people are using to keep from getting Firesheeped, 2. operators of small web sites have noticed HTTPS Everywhere and considered implementing HTTPS in order to prevent session hijacking but have run into hosting cost barriers, and 3. the maintainer of HTTPS Everywhere has not yet provided any guidance on overcoming these cost barriers. --Tepples 12:40, 28 June 2012 (MST)
- ←
I suppose one of us (that is, me) should make a feature request via trac.torproject.org
to have the platform
attribute in rulesets (previously mentioned here) accept a value "sni
," to disable by default such rulesets on OSes that don't support SNI. However, that doesn't help the case where SNI support is lacking at the hosting provider, and I suppose I'm getting on the wrong side of the security vs. functionality divide here. --Eighty5cacao 22:18, 1 December 2012 (MST)
Redirecting to http
"Web site operators who depend on AdSense income may have to redirect anonymous visitors from HTTPS to HTTP in order to show advertisements to these viewers without the pop-up."
So does this mean:
- A 3xx redirect
- A META REFRESH or JavaScript-based redirect, optionally with a human-readable message
- A human-readable message with no automatic redirection but optionally a clickable link (the message would need to explain how to disable any relevant HTTPS Everywhere ruleset if any)
Only (1) causes HTTPS Everywhere to detect that there is a problem and stop rewriting the URL for the current browser session; this is an advantage over (2) in terms of usability. However, I think websites should really be doing (3) so as not to reduce the user's security without adequate consent. Of course, this all assumes that no advertiser has perfect HTTPS support; am I understanding okay? --Eighty5cacao (talk) 04:21, 10 July 2013 (UTC)
- I could do #3 (soft redirect), set a cookie to show that the user has seen the message, and do #1 (302 Found redirection) thereafter. --Tepples (talk) 20:23, 11 July 2013 (UTC)
- If you mean that you are going to implement such a thing on Pin Eight, could it wait until we've investigated other advertisers and sorted out the situation with HTTPS Everywhere? (As far as I am aware, 3xx redirect loops also cause HTTPS Everywhere to stop securing cookies for the offending domain. But with MediaWiki setting the cookies, that doesn't really matter...) What specific timeframe do you have in mind? --Eighty5cacao (talk) 23:21, 11 July 2013 (UTC)
- I didn't mean that I had made plans to put that in place here. I was referring to the abstract case of an ad-supported site. --Tepples (talk) 23:41, 11 July 2013 (UTC)
- The point was that for Pin Eight, I would recommend doing at most #3 by itself, in such a way that the message does not completely replace the intended page content.
- But even that might be moot if AdSense actually has better https support than the Google Support article describes. When I checked your homepage with Live HTTP Headers a few minutes ago, the Twitter Spelling Test image appeared to be the only mixed content. This was not always the case. Admittedly, HTTPS Everywhere was rewriting the initial
pagead2.googlesyndication.com
URL, which you should probably make protocol-relative. It's possible that the script's later requests to tpc.googlesyndication.com
also have active rewrites (meaning they would cause mixed content in a browser without HTTPS Everywhere), but I need to recheck. --Eighty5cacao (talk) 04:35, 12 July 2013 (UTC)
Uncomment
|
todo: keep testing... what about ads with images?
|
- That's one thing I don't really like about AdSense: Last time I checked the manual, I couldn't turn on still-image ads without also turning on "rich media" ads, which the manual explains as ads animated with SWF or JavaScript. Nor does AdSense appear to respect people behind slow or metered connections; they seem to think 150 kB is a "small" ad when it's a half minute download on dial-up or EDGE. I refuse to put SWF advertisements on Pin Eight; in fact, the first thing I ever edited a hosts file for was to black SWF ads. So I think most ad units on this domain are set up for text. --Tepples (talk) 15:12, 12 July 2013 (UTC) (more 18:35, 13 July 2013 (UTC))
- Ok, I admit I'm not that familiar with how AdSense works beyond the official documentation, because I normally block all ads. (Sorry about that. I've got a lot going on in my life right now, but I will consider donating later... Then again, I don't look at your site's homepage anywhere near as often as the wiki.) --Eighty5cacao (talk) 16:40, 12 July 2013 (UTC)
Arbitrary section break: Digression about Slashdot discussion
In the Slashdot discussion you referenced here, specifically [1] (NB: beta):
"What would you recommend for a graphic syndicated from The Oatmeal, which doesn't support HTTPS at all?"
I've got a couple suggestions, in decreasing order of preference:
- Replace the embedded image with a hyperlink, preferably with some text to warn the user about the lack of HTTPS support
- Host a copy of the image on Pin Eight. The advantage of this is that it protects against the possibility of The Oatmeal automatically deleting the image in the future. The disadvantage is that it may violate copyright; The Oatmeal's about page does not contain terms of use, nor any obvious way to find the terms of use except by contacting the author. The contact page implies that Facebook is strongly preferred for non-business inquiries, but it mentions "licensing" as a category of business.
If you want to try contacting The Oatmeal anyway, my suggested line of tech evangelism is: The Oatmeal appears to use Amazon S3 for most images except quiz results. Could this be changed? Admittedly it might be impractical to move existing quiz results to S3. --Eighty5cacao (talk) 19:00, 7 August 2014 (UTC)
- I think the mention of "licensing" as a "business" inquiry relates to paid syndication, say of comics. I don't feel like paying just to brag about my spelling achievement. So I implemented #1 today when I upgraded the AdSense code to the newer HTTPS-compatible version. --Tepples (talk) 22:27, 7 August 2014 (UTC)
- Yeah, I knew I was using the word a little sloppily there. But does the AdSense fix obsolete your previous request to split a proposed HTTPS Everywhere ruleset into two parts? --Eighty5cacao (talk) 22:44, 7 August 2014 (UTC)
- There are a few pages that use different ad shapes (and hence different ad code) that I still need to fix, mostly within the /ds/ directory. And I can't guarantee that pics.pineight.com/... and pineight.com/pics/... will remain synonymous forever. --Tepples (talk) 00:16, 8 August 2014 (UTC)
- Ok, sorry for forgetting.
Proposed solution to be described here once I implement it --Eighty5cacao (talk) 04:40, 8 August 2014 (UTC)
- I was really only apologizing for forgetting about
pics.pineight.com
. My goal is for that to be the only thing that's default off, as the developers do not normally consider mixed-content blocking of third-party ad and tracking scripts important enough to justify disabling a ruleset. (See comments that contain the wording "no one cares[dead link].")
- For now, I decided to add coverage just for the homepage. To really cover the homepage, though, I'd need to know whether some HTML document filename is equivalent to
/
(is it index.htm
or something else?). --Eighty5cacao (talk) 05:12, 8 August 2014 (UTC)
- I use
Options MultiViews
to serve documents without a file name suffix, which makes /index.php, /index, and / synonymous. --Tepples (talk) 17:38, 8 August 2014 (UTC)
- Fixed, I think. --Eighty5cacao (talk) 18:00, 8 August 2014 (UTC)
HTTPS doesn't stop SOPA-alike tactics
This was prompted by "Connection reset by peer" and timeouts that I was experiencing soon after visiting the front page of IsoHunt's mirror of The Pirate Bay after news broke of its existence. Don't know if related, but I'm leaving this here in case I decide to make a more general article about HTTPS.
In the 2010s, several countries were considering legislation analogous to the proposed Stop Online Piracy Act and PROTECTIP Act to require ISPs to implement technical means of preventing users from visiting a particular site that contains politically incorrect works, such as works that are sexually explicit, lese majeste, or a parody of a work controlled by a powerful publisher. Or ISPs with organizational ties to Hollywood, such as cable ISPs, might implement similar means through private contracts with powerful publishers. For example, an ISP could forge DNS results, or it could inject RST
into a connection after the HTTP Host:
header. TLS doesn't help, as even with TLS, an ISP can still censor hostnames that provide politically incorrect works without affecting innocuous sites on the same IP. For example, the ISP can eavesdrop on TLS client hello messages, pull out the (plaintext) SNI hostname,[ref]makerofthings7, Steve Dispensa. "Can wildcard certificates hide/obscure the hostname in a TLS connection?" Information Security Stack Exchange, 2011-09-30. Accessed 2014-12-13.[/ref][ref]Zack. "Answer to How does a country block/censor an encrypted website (HTTPS)?". Information Security Stack Exchange, 2011-09-30. Accessed 2014-12-13.[/ref] compare it to a blacklist, and either inject RST
or drop all packets to that IP for several seconds. --Tepples (talk) 17:34, 13 December 2014 (UTC)