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)
This is pretty deep down the threat modeling hole though, and no, normal people don't need to care about this.
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.
Remember Upside-Down-Ternet? [1]
But who is going to set up a hostile router in an office of five people? Or in someone's home?
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.
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?
"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.
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.
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.
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.
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.
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://www.troyhunt.com/ive-just-launched-pwned-passwords-v...
Unsecure http is essential to the free flow of information.
Let's get the right solution before we force everyone to use it.
Devices that can be made to update on the whim of some corporation (which can be compelled by the government) are also not at all secure.
I don't consider my house secure if the lock company and the police have a skeleton key to my front door.
Open devices that can use open protocols are best. That is why they are trying to deprecate them.
I don't think it is at all far fetched. We've already seen domain registrars in the United States arbitrary delete domain names for purely political reasons that they made up on the spot. Why not revoke certificates from websites that they find objectionable?
It's not like most users would know how to force their device to connect anyway. On many Android devices, it is virtually impossible to force your browser to connect to a site Google doesn't want you to. But they've gotten this far because we trust them to only protect us from malicious sites.
Am I being paranoid for not trusting Google, Facebook or the federal government?
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 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.
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.
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).
Tiny addendum, what I saw was different by one version: DarkSky worked fine in Mavericks, just not Mountain Lion.
<?
header('Access-Control-Allow-Origin: *');
$url = $_GET['url'];
echo file_get_contents($url);
http://theWebServer.com/thePhpFile.php?url=https://darkSkyURL
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!
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.
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.
Luckily, Dashboard widgets are just editable html and javascript files, so I rewrote a portion of Apple's weather widget to use the DarkSky API instead. Since the entire point of this project was to support a legacy feature (the Dashboard), I really wanted it to work on the full gamut of OS X 10.4 Tiger – 10.14 Mojave.
My modified version worked fine on 10.9 and above, but on 10.4 – 10.8, users reported being unable to retrieve any weather data. After some back and forth of looking at logs, I found the problem—old versions of OS X didn't support the modern iteration of HTTPS required by DarkSky. I couldn't fix this, because DarkSky doesn't offer their API via HTTP.
Was this really necessary? 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?
(Luckily, I had the chance to rectify this when Apple bought DarkSky and forced me to change APIs. I'm now using Weatherbit, which offers HTTP. I would have preferred to use HERE, but like DarkSky, they're HTTPS-only.)
https://forums.macrumors.com/threads/i-fixed-apples-broken-w...