> Weather forecasts are public information, so what level of safety is provided by HTTPS to the point where it should be not just a default, but the only option for developers?

Even if it's public information, you should protect against an attacker modifying the payload to exploit a weakness in your browser/application, and to protect against any any other kind of unauthorised modification of the payload. (I see Cthulhu_ already mentioned this.) We've discussed the non-obvious advantages of HTTPS before. [0][1] There's a reason Netflix encrypt video streams. I agree it's probably not worth breaking existing applications to encrypt the weather data, but it's worth doing going forward.

[0] https://news.ycombinator.com/item?id=22933774 (Forgive me linking to my own comments)

[1] https://news.ycombinator.com/item?id=21912817

Fetching a weather forecast reveals that I was in a certain location. Depending on circumstances, that could easily be incriminating evidence. Yes, Dark Sky should be HTTPS by default.

Also could imply where you're going to. Looking up the weather in London (if I don't normally) almost certainly entails a trip.

This is pretty deep down the threat modeling hole though, and no, normal people don't need to care about this.

What, you don't bombard weather APIs with dummy requests about random cities so as to obscure where you might be going?

When baseball season is actually occurring I will sometimes look up weather in a half dozen cities around the country to get an idea of which games might get rained out. Not exactly the same thing but I'm not actually traveling to any of them.

Normal people don't even know what HTTPS means!

That's why we like to use it everywhere: to protect the people who didn't know they needed protection.

HTTPS does not encrypt the source and dest IP of your packets, right? So HTTPS can't hide who you are and what APIs you're talking to.

The IP of my phone connecting to the IP of Dark Sky is much less precise than the request for GPS coordinates to get block level weather data (the Dark Sky website uses 12.345 digits, so is accurate to block level).

This is where the arguments start to get a bit silly. If the authorities are trying hard enough to find you and your phone is on, the network it is attached to can probably locate you very accurately under most conditions already.

HTTPS is useful, and it should normally be the default for web traffic potentially crossing any untrusted network, but let's keep it in perspective. It's an application layer protocol. It can't protect you against attacks at lower layers.

It's not authorities, anyone setting up a router can peek into this information, and more importantly, tamper with it.

Remember Upside-Down-Ternet? [1]

[1] http://www.ex-parrot.com/pete/upside-down-ternet.html

Right, which is why I said HTTPS should be the default for web traffic potentially crossing any untrusted network.

But who is going to set up a hostile router in an office of five people? Or in someone's home?

Correct. TLS-wrapped protocols don't seek to offer anonymity of the source and destination. They're designed to protect the confidentiality and integrity of data in transit. The best tools we have for anonymity are things like onion routing.

Yeah, I regularly ask clients to drop TLS support for their public-facing API's that aren't consumed by the browser. These are the same clients that shared a public-facing FTP server to partners to allow them to retrieve catalogue's of prices and product descriptions.

The admin of having to rotate keys and help customers with their TLS and SSL related problems (which is many in Enterprise, Java 5 and 6 is fucking rampant still) just isn't worth it.

Yes, someone could MitM the connection. Do we care? No. The data has very little consequences if it's corrupted.

Maybe you have to include a secure access key with every request? Maybe DarkSky sets a cookie that they do not want anyone to be able to intercept or manipulate?

HTTPS by default is good, because you don't know what could go wrong. What if there's a security vulnerability in the dashboard widget that someone who can intercept and manipulate the response can abuse?

Correct, for DarkSky the API key is embedded in the request URL [0]. Their pricing is generous (1000 requests/day are free, after than $1 per 10,000 requests) but there is definitely the risk that traffic over HTTP could have the URL sniffed, and then be used to make charges on that customer's behalf.

0: https://darksky.net/dev/docs

I agree. I treat cyber security a lot like physical security.

"Always lock your front door" is good advice, just like "always use https" is good advice. But I'm not going to lock and deadbolt my door if I'm only walking out to grab something from my car and returning immediately.

The issue is that an MITM attacker can modify the traffic between client and server if it's not protected by HTTPS.

They could include a script tag and then run JS in the context of the widget which may have undesirable effects.

If the traffic is traveling over a connection you aren't 100% sure you control entirely, wrap it in HTTPS.

I can confirm this 100% with Charter / Spectrum. They use MITM to alter HTTP content to display their TOS you have to agree to in order to stop redirecting the content.

The only workaround is to use a VPN since so many servers still have not moved from HTTP to HTTPS.

Tech support states unless I accept the agreement this will not stop and may connection will be disconnected which is complete BS since HTTPS prevents this from working properly!

So yes, even ISPs are bad actors when it comes to HTTP.

I use Spectrum at home, as do my grandparents, and in neither case have I ever seen that happen (and I do access at least a couple non-HTTPS sites every once in awhile). Was that recent?

That's not a concern for a REST API where you are just grabbing and parsing json data. Even if someone injects some code into the result, it just gets parsed as a string and the worst thing that happens is the widget displays the wrong thing.

Fine so they modify the a field in the object, the point made was that you don't want to ingest anything other than what which is provided by the expected and hopefully trusted author.

Yours was a facetious point to make. Potential worst case scenario in this example may be that someone thinks its the wrong temperature, but normalising and arguing against the use of secure protocols is stupid and dangerous.

I'm not arguing against security. I literally said that using https is a good idea.

The point I'm making is that security always comes at a cost, and sometimes it just isn't worth it. In the OP's example, using https literally breaks the application. Whereas switching to http has very little downsides. So while https should be seen as the default, it makes sense to use http sometimes.

Do you use full disk encryption on every machine you use, with a separate TFA key for every device? Do you have bullet proof windows and a reinforced steel door? Have you purchased and set up a commercial firewall for your home network?

You can always increase security. Where you draw the line depends on you and your application. Throwing out all nuance because "you must always use $SecureThing at all costs" is just not helpful.

> the point made was that you don't want to ingest anything other than what which is provided by the expected and hopefully trusted author

What you actually said went quite a bit further than that. You outlined a scenario that involved arbitrary code execution.

> Yours was a facetious point to make.

"Facile", maybe? Even with that correction, the point was not facile—after all, it forced to you walk back from the original picture you painted of an RCE to a place where someone may get told there's going to be a mid-summer blizzard.

https://rationalwiki.org/wiki/Motte_and_bailey

Until somebody finds a vulnerability in your JSON parser or other layers of your stack. :)

There are inherent, unfixable vulnerabilities to a weather app, such as divulging location information and possibly travel patterns.

If you request weather info for a large range of locations at once - the k-Anonymity that HAVE I BEEN PWNED uses - you could prevent this at the cost of increasing response size dramatically

https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...

I don't think that would help much. If my phone tries to get weather data for the prefix "66" and then "a9" and later "8d" and you correlate the cities together, you can be pretty sure I was driving around the Bay Area if the first list contains "Cupertino", the second "San Jose", and the third "Palo Alto".

I was thinking less around prefix matching and more around requesting enough data to where an observer couldn't tell what I was really interested in. If I requested 100 distinct locations in every state - 5000 total - you would know I was interested in the United States, but you would have a hard time determining where specifically.

But if the list from California always contained cities in the Bay Area that would be a bit suspicious.

It might be for this app but say the app displayed an image of the cloud cover. That image, from a MITM could be designed to exploit a know decoder bug (project zero just had a post about bunch they found in Apple's OSes). Browsers (or at least Chrome) run the image decompressors in the sandbox. Does Dashboard?

If the threat model is random exploits, they can still do that. Heartbleed etc have shorn that even the TLS stack itself can contain catastrophic vulnerabilities, so it's likely there will show up more in the future.

Or, maybe, just treat untrusted inputs as untrusted inputs and act accordingly. Wrapping it in encryption does nothing if the API provider gets hacked.

The other issue is that a certificate-based model of trust can be wielded by governments to censor the internet.

Unsecure http is essential to the free flow of information.

Let's get the right solution before we force everyone to use it.

Don't force anyone to use it. Both HTTP and HTTPS can be used, in addition to other protocols such as SMTP, NNTP, Gopher, Telnet, SSH, etc. To ensure to have free internet, to allow all protocols including if someone invents a new one, and including if someone uses non-standard port numbers for whatever reason, and including in both directions (anyone can act as a server or as a client or both).

If governments want to censor the internet, insecure protocols only make it easier for them.

It would be great if people could correct the record instead of just cowardly downvoting me. If I am presenting something that is untrue, please let me know.

Am I being paranoid for not trusting Google, Facebook or the federal government?

You bring up an interesting case.

On the one hand, we have matter of privacy - people presumably request the forecast for their present location, or their travel destination. This may be sensitive information, depending on personal circumstances.

On the other hand, we have usability - in the name of security, people got stopped from using a convenient feature. This seems pretty close to the trouble of planned obsolescence, and seems to be a somewhat common trend, of security running counter to usability and hackability (in the DIY sense).

I spend a lot of time playing with old Macs, and so I’m used to anything internet-related being broken due to TLS or defunct URLs. So, I was pleasantly surprised when installing Mac OS 9 one day that Apple’s NTP servers are still just as they were 20 years ago.

> the modern iteration of HTTPS required by DarkSky.

I don't follow. The TLS handshake negotiates the appropriate ciphersuite. With the exception of dropping SHA1 in TLSv1.3, how was the macOS SSL module not able to negotiate a handshake? There should be plenty of suites available. What did Darksky ask for in the TLS handshake???

For example: I'm still running Mojave, and here's what I see from the handshake with the Darksky.net site on :443 ...

:

:

issuer=C = US, O = Amazon, OU = Server CA 1B, CN = Amazon

---

No client certificate CA names sent

Peer signing digest: SHA512

Peer signature type: RSA

Server Temp Key: ECDH, P-256, 256 bits

---

SSL handshake has read 5538 bytes and written 439 bytes

Verification: OK

---

New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256 :

:

:

They aren't even using TLS1.3 on the main page.

Keep in mind that Mountain Lion is a lot older than Mojave. If I go to SSL labs and test DarkSky.net, it shows a "protocol mismatch" for Mountain Lion and older, which is exactly what I saw with the widget:

https://www.ssllabs.com/ssltest/analyze.html?d=darksky.net&s... (scroll down to "not simulated clients" and click "expand).

I don't actually understand that much about the internals of https, but my assumption is that there weren't any cipher suites supported by both DarkSky and Mountain Lion.

It's not cipher suites it's the entire TLS protocol version.

That site requires exactly TLS 1.2 (not newer or older)

So an HTTPS implementation like Mountain Lion that only speaks TLS 1.1 or earlier will begin by saying it can do TLS 1.1 and the server says too bad, go away.

TLS 1.2 was defined in about 2008 but despite that a lot of products shipped without TLS 1.2 implemented for the next several years, because backwards compatibility meant they still worked, and it didn't seem like a priority, while forward compatibility had frequently proved problematic. Why ship something "more secure" that breaks for 1% of your users?

For example Firefox only added TLS 1.2 by default in 2014, after Mountain Lion was shipped (but before it ceased to be supported).

Wow, that's really cool. Googling around it appears that Mountain Lion wasn't upgraded to TLSv1.2 so any website that upgraded to TLSv1.1 broke on pre-Yosemite. I didn't realize this. Very interesting.

> any website that upgraded to TLSv1.1 broke on pre-Yosemite.

Tiny addendum, what I saw was different by one version: DarkSky worked fine in Mavericks, just not Mountain Lion.

Could you have bypassed DarkSky’s TLS version requirements by proxying the API requests through Cloudflare or some other TLS forward proxy?

You can use a proxy, yes. The workaround I suggested to users on OS X 10.4 – 10.8 was to set up a web server with the following PHP file:

    <?
    header('Access-Control-Allow-Origin: *');
    $url = $_GET['url'];
    echo file_get_contents($url);

And then edit the dashboard widget's API request url to point to:

    http://theWebServer.com/thePhpFile.php?url=https://darkSkyURL

But, this required users to have access to a web server.

I very briefly considered setting up a public instance, but I'm not a professional web developer and didn't know what the implications would be, either for the overall security of my server, or in bandwidth costs, particularly if malicious users started using the "proxy" for other things. All of the client-side code is out in the open, so it also wasn't clear how I'd make an authentication scheme. I'm sure there's a way, but again, not a web developer!

I think the suggestion is to skip a web server at all and go "serverless" with Cloudflare Workers, which are free for up to 100,000 requests/day: https://workers.cloudflare.com/

If your Worker code hardcodes the Dark Sky domain, the worst an attacker could do is either use up your free worker quota from Cloudflare, or hammer Dark Sky at the Worker ratelimit (1,000/minute, which Dark Sky should easily handle).

AWS, Azure, GCP all also have free tiers for their serverless services. RunKit (http://runkit.com) might also work.

These are all likely to be HTTPS-only, but hopefully at least one of them supports TLS v1.1, rather than being 1.2-only like apparently is the problem with Dark Sky.

Serverless would work but my initial idea was more basic, simply a combination of something like:

A. DNS record (foo.example.com CNAME api.darksky.net)

B. TLS forward proxy (e.g. Cloudflare Full SSL https://www.cloudflare.com/ssl/)

C. Host header rewrite (e.g. Cloudflare Page Rules https://support.cloudflare.com/hc/en-us/articles/206652947-U...)

> I stopped using the Dashboard weather widget when I realized it was giving me the weather for Minneapolis, Kansas, because it was ignoring the state part of the location, and Kansas comes before Minnesota alphabetically.

Huh, that's odd—it's absolutely programmed to look at city and state individually. I had to interface with that code in my version.

When I type Minneapolis into my version, it correctly displays both cities (alongside Minneapolis, NC) the drop-down, and lets me choose between them. I would have expected the original to do the same thing, but I obviously can't check now.

Sorry, I wasn't clear. This was back in 10.4 or 10.5. I remember seeing Apple had fixed it in a later version like how you describe.