Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Bureau of Meteorology website does not support connections via HTTPS

bom.gov.au

Post reply on HN
Print view View original

31–40 of 58 posts

Re: The Bureau of Meteorology website does not support connections via HTTPS

#31

Post by lgeorget »

JonathanBeuys wrote: post #25

HTTPS is still a pain in the ass, even in 2024. If letsencrypt would offer wildcard certificates with their url based authentification as they offer for non-wildcard certificates, it would be ok. But having to tinker with the DNS infrastructure for each project which wants to use domain wide HTTPS is so much hassle.

It depends on your provider though. I can tell from experience that with OVH and their API, it's been easy to set up the automatic renewal via DNS verification. Apparently, the official client has support for the DNS API of 159 providers: https://github.com/acmesh-official/acme.sh/wiki/dnsapi

Re: The Bureau of Meteorology website does not support connections via HTTPS

#32

Post by matrss »

ulrischa wrote: post #19

Controverse opinion: Why do I need https when looking for the weather forcast. Https is blindly thrown on everything. If the data is public and no login or personal/sensitive data is involved why do I need https?

> If the data is public and no login or personal/sensitive data is involved why do I need https?

Do you care about if the data actually comes from your weather forecasting service and was not tampered with by a third party? Then you need https as well.

A different example: a podcasts website I've seen was served over http, and someone argued the same (data is public, no login). The page contained an IBAN for donations. That would be a valuable target to replace as an MitM.

Re: The Bureau of Meteorology website does not support connections via HTTPS

#33

Post by L_226 »

Remember when BoM was pwned [0] by a foreign intelligence service?

What about when they wasted $220k [1] on rebranding but ended up scrapping it?

[0] - https://www.itnews.com.au/news/asd-reveals-how-the-bureau-of... [1] - https://www.abc.net.au/news/2022-10-19/bureau-meteorology-re...

Re: The Bureau of Meteorology website does not support connections via HTTPS

#34

Post by rini17 »

harrymit907 wrote: post #24
ulrischa wrote: post #19

Controverse opinion: Why do I need https when looking for the weather forcast. Https is blindly thrown on everything. If the data is public and no login or personal/sensitive data is involved why do I need https?

Your LE friendly ISP can insert a JS browser exploit and gain access to your device. Is that a valid reason?

Meh, that's all such a theater. LE can ask anyone to insert an "JS exploit", especially into the government meteo service. It will then be nicely safely and securely served to you via HTTPS :) Of course, enabled specially for your IP address so that noone else gets any clue.

edit: and everyone is voluntarily mitming via cloudflare anyway..it's all such a farce

Re: The Bureau of Meteorology website does not support connections via HTTPS

#36

Post by Strilanc »

kspacewalk2 wrote: post #5

What practical difference does it make if I connect to an Australian weather forecast site via HTTP or HTTPS? Is the NZ secret police gonna MITM a rain forecast my way when it's actually gonna be a very sunny day?

A government site has implicit authority. You could use that implicit authority to make a scam look more authentic. It also will have a lot of traffic; a lot of opportunities for the scam to work if you do manage to get in the middle.

For example, inject a dialog box that says "Our records indicate your taxes were not paid this year! Before you can view the weather you must click here and log in to resolve this issue!".

Re: The Bureau of Meteorology website does not support connections via HTTPS

#37

Post by Beldin »

defrost wrote: post #12
geek_at wrote: post #7

Earlier quoted context omitted.

It's just dangerous because any party on the way between wifi and the server can edit the content See: why are free proxies free https://blog.haschek.at/2013/05/why-free-proxies-are-free-js...

In the same way as walking to the bank is dangerous because any party on the way can rob you on the way? I regularly visit: www.bom.gov.au/ /forecasts/ .shtml It either shows me the forecast or it doesn't. To date it's always worked - if one day it doesn't I might have to look out of a window.

> In the same way as walking to the bank is dangerous because any party on the way can rob you on the way?

To make this analogy more fitting, you'd also need a big sign around your head "going to do some banking, carrying all necessary credentials, cannot tell legitimate bank from fake bank".

Still not a great analogy though.

Re: The Bureau of Meteorology website does not support connections via HTTPS

#39

Post by slowbdotro »

Back in 2013-15 I was fortunate enough to know some people at BoM, specifically done IT people.

Their off hand comment around why BOM didn't have https was due to the amount of overhead and infrastructure changes needed to make that https change.

Fast forward to 2018ish they recently created a new API, and a new website. Https://Weather.bom.gov.au with https enabled! (which I now have integrated into a raspberry pi and an eink display for my morning weather).

For whatever (archaic) reason the new weather webui is now defunct but the api still exists, uses https, and as far as I know supports their mobile applications.

All it would take is for some ISPs here to mitm the traffic with ads / junk and maybe they would change it. The upside to this story is that it is currently a great site to visit for captive portal detection.

Re: The Bureau of Meteorology website does not support connections via HTTPS

#40

Post by comprev »

matrss wrote: post #29
pophenat wrote: post #15

I find intriguing their explanation about how to use their FTP service and why it’s not possible to access it with a modern browser. http://www.bom.gov.au/catalogue/anon-ftp-hints.shtml

They make an (easily made) mistake on that page: the encrypted version of FTP is not SFTP, but FTPS. SFTP is an entirely different protocol based on SSH.

HTTP to HTTPS is FTP to FTPS.

"cp" to "scp" is FTP to SFTP, i.e "secure" prefix.

Post reply on HN