I can't say in this instance, but some package updates are backports of security patches that are written for later releases, so when backported to an older release, the major.minor numbers don't change, and only the patch release suffix changes. Might be the case here.

The problem that SNI solves is to do with privacy. For non-TLS traffic, a webserver can have multiple hostnames (vhosts?) at the one endpoint, and it knows which vhost to use based on the hostname in the Host: header that the client sends in its web query. Without the Host: header, the server can't know which website the client is wantint to access. The DNS name is passed from client to server only in the Host: header.

Under pre-SNI SSL/TLS implementations, the secure tunnel is built with no information about either end, and then the client sends a Host header to say what website it wants to connect to. But in order to establish the tunnel, the certificate must already have been selected to authenticate the server to the client. The Host: header has the website domain name in it, but the Host: header isn't sent until AFTER the TLS tunnel is established, including certificate selection. We have a chicken-and-egg situation.

How SNI solves this is that the website domain name is sent within the TLS negotiation, so that the webserver can choose the right certificate before the Host: header is selected.

If the SNI value is missing from the TLS negotiation, the webserver doesn't know which website is required, and doesn't know which certificate to use to authenticate with. In previous versions of Apache, the behaviour where the hostname was not available through SNI was insecure. A user who is permitted to access one vhost could leverage this lax SNI handling to access a different vhost that they aren't granted access. I believe the patch locked this down, causing strict SNI behaviour by default. The end result is that in some configurations, SNI is now required.

Cheers
Jeremy

On Tue, 22 Jul 2025 at 13:23, <betsys@well.com> wrote:

Thank you both, that worked

Yes, apologies if it was unclear, the upgrade to ubuntu 8.7 did replace the 2.4.58-1ubuntu8.6 package with 2.4.58-1ubuntu8.7

Annoying that a change that doesn’t change the rev number seems to have changed several behaviors, both this and the charset.

 

I confess I’m not entirely clear about how SNI is involved when the webserver has one hostname and the cert has one hostname and xymon is trying to connect to that hostname by name.

Is it related to the fact that the hostname is attached to a vhost and not to the overall apache instance?

 

Thanks again and may all your blinky lights be green.

 

From: Jeremy Laidman <jeremy@laidman.org>
Sent: Saturday, July 19, 2025 8:16 PM
To: Xymon mailinglist <xymon@xymon.com>
Cc: Adam Thorn <alt36@cam.ac.uk>
Subject: [Xymon] Re: https "Misdirected request" monitoring after target ubuntu 8.7 update

 

Adam, thanks for the follow-up with more detail and more accuracy.

 

On Sun, 20 Jul 2025 at 02:21, Adam Thorn via Xymon <xymon@xymon.com> wrote:

I suspect the priginal poster did in fact upgrade apache : they meniion
"8.7 update", which I suspect means moving from  2.4.58-1ubuntu8.6 to
2.4.58-1ubuntu8.7 which was released a couple of days ago for Ubuntu 24.04:

 

That was my thought too, but all of their examples show the same version in the Server header:

 

Server: Apache/2.4.58 (Ubuntu)

 

*looks more closely*

 

Ah, I see what you mean. The update was at a patch level, not a major.minor release level, so the Server header would not have changed as a result of this update.

 

Minor correction to Jeremy's post: note that the xymonnet docs say that
the flag to add (if updaating the xymonnet entry in tasks.cfg) is
--sni=on , not just --sni.

 

Grateful for your keen eye. I was looking at the hosts.cfg(5) man page which only mentioned the "--sni" option for xymonnet and not how to use it. I should've followed through with a review of the xymonnet(1) man page, before pretending to have any degree of experience.

 

<snip>

 

Cheers

Jeremy

_______________________________________________
Xymon mailing list -- xymon@xymon.com
To unsubscribe send an email to xymon-leave@xymon.com