Searching RISCOS Open

When searching RISCOS Open site on a phone I get this error- This server could not prove that it is www.riscosopen.com; its security certificate is from www.riscosopen.org. This may be caused by a misconfiguration or an attacker intercepting your connection

- Any Ideas?

Have you gone to the wrong site to do your search? This site is www.riscosopen.org

The domain name is riscosopen.org, not riscosopen.com

The certificate of the server is for www.risosopen.org and is valid only for that server – i.e. host = www in the domain riscosopen.org

It is possible to have SAN values that allow for other host names and other domains, but that isn’t the case for this certificate:

| ssl-cert: Subject: commonName=www.riscosopen.org
| Subject Alternative Name: DNS:www.riscosopen.org, DNS:riscosopen.org

Edit I should probably add that www.riscosopen.com does resolve to the same IP as www.riscosopen.org, so either name is valid in DNS, but the certificate doesn’t match up.
This could be corrected by adding www.riscosopen.com as a Subject Alternative Name when the certificate is next renewed. Doing it early may be an unwanted expense for ROOL.

Edit2 You probably haven’t noticed before as you’ve used browsers are doing http first and the redirect on the server takes you from http://www.riscosopen.com to https://www.riscosopen.org, your phone is likely doing HTTPS first and thus going direct to https://www.riscosopen.com and hitting the certificate invalidity and then warning you of a possible Man-in-the-Middle attack because the HSTS enabled on the server is instructing the browser to do exactly that.

An unfortunate consequence of enabling the HSTS while having a certificate that doesn’t match all possible DNS names

Edit typo corrected

[Covered by Steve’s Edit 2]

One thing that web site maintainers should note is that real world¹ browsers are increasingly adding “HTTPS first” as a feature in a progression to having it as a default option and then mandatory.

So, if you have a web site, you need to look at a number of things:

1. Adding properly certificated HTTPS if you don’t have it.
2. Checking the certificate matches all possible DNS names
3. enable HSTS if you need it² but remember the previous point – the certificate must match.
   Be mindful that typical TLS/SSL proxies (e.g. OpenDNS) do their inspection by a technique identical to a MtM attack, so enabling HSTS on your server may stop it being accessed by anyone connecting through that style of proxy.

Hmmm, day 5 of leave and my mind is switching back into IT support mode. Maybe a bit of gardening instead.

¹ Real world browsers as opposed to RO browsers.

Have found works search – “Riscosopen.org USB floppy William”

Does anyone know what happened to William?

Think he gave up on that: https://www.riscosopen.org/forum/forums/5/topics/8961?page=2#posts-84937

The site is misconfigured.

There are various aliases in use (. org.uk, .co.uk), and in a quick test, only the .org.uk redirects.

I think this is best handled by a DNS entry (CNAME?) to tell everybody that .org is the preferred domain. ¹
Like that, everybody will end up in the right place and there won’t need to be multiple certificates to keep track of.

Be aware, a fair few Google searches for ROOL stuff will take you to the wrong domain and it will cause scary warnings to appear.

¹ That’s how going to the .co.uk version of my site tosses you over to the .eu one.

I should probably add that www.riscosopen.com does resolve to the same IP as www.riscosopen.com

Why wouuld it not?

Why wouuld it not?

Quite a number of reasons, foremost:

1. If someone else owned the domain name and had it pointing at their host
2. if the owners of the domain name actually had it pointing to a host on a different IP

That’s not the point though. The point I made was that although the two URLs resolve to the same IP, the behaviour of the browser on getting to that IP depends on the URL used to get there.
The behaviour also depends on the protocol in use. Use of http for the .com URL will give a redirect to the .org, use of HTTPS to connect to the .com will hit an error message when the certificate is checked and fails to match the .com URL
You could get the same error by putting the IP 91.203.57.172 into the browser – even NetSurf.

Rick is right that changing the DNS by replacing the A record of www.riscosopen.com with a CNAME of www.riscosopen.com —> www.riscosopen.org would have the client browser expecting to connect to www.riscosopen.org
Similarly, for the .co.uk and .org.uk versions.

However, he will find that .co.uk does redirect, when the initial connection is on HTTP
It’s a server based redirect of connections to https://www.riscosopen.org, which, given that even NetSurf complains if you specify HTTPS as the connection method for www.riscosopen.com, presumably means that RO users are in the habit of connecting by only specifying the URL and not HTTP or HTTPS.

You need to read what you posted.

You need to read what you posted.

Yep. Typo. Should be …same IP as www.riscosopen.org

Although the comments 1 & 2 above are correct too.

The point I made was that although the two URLs resolve to the same IP, the behaviour of the browser on getting to that IP depends on the URL used to get there.

As an example: uhmeded.uhcw.nhs.uk or apps.uhcw.nhs.uk (and a few others)

The cert is a wildcard so applicable to all, the URL determines the target host and port used to connect to the host. A bit more complicated than any RO user needs though.

presumably means that RO users are in the habit of connecting by only specifying the URL and not HTTP or HTTPS.

Speaking only for myself… I’ve bookmarked the Recent Posts page, and I just call up the bookmark and go from there.

I think Android Chrome these days tries hard not to deal with http only sites. Leading to the interesting situation in that if I find a PDF datasheet and it’s on a non-encrypted site, I’ll simply get a blank window with a lengthy google.com URL at the top.
But if I choose to specifically open the link in a new tab, the redirect will work and the PDF will download. Same if I unGoogleify the URL, but given it’s hundreds of characters of gibberish and MIME encoded (like %3F or whatever for /), it’s just easier to do the new tab thing.

Google’s A-grade programmers at work again. <sigh>

William of Acorn USB floppy drive fame talked about contacting Sprow did this happen?

William Email address!

Just fiddled with my site, and it looks like the redirects are simply 301s set up in the .htaccess file, and the reason the “www.heyrick.co.uk” doesn’t choke is because it’s listed as an alternative in the certificate data; along with the alternate “www.heyrick.eu” and the main “heyrick.eu”.

That works too. Either way, ROOL needs to sort out how the aliases are handled because modern browsers default to trying https and, well, awooga! this is bad!

Should I even mention the lack of an AAAA record? ;)

If you’re looking at a possible way to get data from an old floppy, then this might be of interest:
https://retroready.one/products/greaseweazle-v4-usb-floppy-adapter-flux-reader-writer-amiga-atari-pc

You’ll need some sort of PC (unless anybody fancies taking a crack at writing a driver?) to communicate with the device.

And there are plenty of us with functioning RISC PCs etc. with floppy drives.

Should I even mention the lack of an AAAA record? ;)

I’m looking to retire before someone insists we have to have IPv6 connectivity