back-channel on front-channel port

Nate Klingenstein ndk at
Tue Jun 29 06:09:11 UTC 2021


Not to channel the boss, but I think he means that if your servers are behind a reverse proxy that terminates TLS connections, as is common, much of the TLS information may not be available to the servers themselves, depending on the reverse proxy, and you're presuming the reverse proxy itself won't be compromised in some form, and that commercial CA's have made mistakes signing improper certificates before.  As such, it's not really complete end-to-end security in many deployment scenarios.  Signatures on the messages with certificates in metadata can help alleviate that, but they can't prevent some of the attacks that a man in the middle could perform with the decrypted message.

Pretty much under no circumstances is certificate authentication not advisable today given how fast TLS is and the extra layer of security it offers, but it is not a complete stand-in for end-to-end encryption using certificates that are more reliably signed.

Have a good day,

Signet, Inc.
The Art of Access ®

-----Original message-----
From: Bergmann, Clemens
Sent: Tuesday, June 29 2021, 5:51 am
To: Shib Users
Subject: AW: back-channel on front-channel port

Hi Scott,

thanks again for the fast reply but I don't understand fully what you are recommending. 
Do I understand you correctly that you suggest that certificate authentication is not needed nowadays and therefore the additional port can be ignored?

Mit freundlichen Grüßen
Clemens Bergmann
Clemens Bergmann
Gruppe Nutzermanagement und Entwicklung
Technische Universität Darmstadt
Hochschulrechenzentrum, Alexanderstraße 2, 64289 Darmstadt
Tel. +49 6151 16 71184 <>/

> -----Ursprüngliche Nachricht-----
> Von: users <users-bounces at <mailto:users-bounces at>> Im Auftrag von Cantor, Scott
> Gesendet: Montag, 28. Juni 2021 16:34
> An: Shib Users <users at <mailto:users at>>
> Betreff: Re: back-channel on front-channel port
> You don't have to do anything special, and no, you can't really rely on
> certificate authentication like that, it doesn't work reliably when it's not host-
> based and there's no intent that it would work. The messages are signed
> instead, and the possibility of MITM exposure is simply ignored.
> -- Scott
> --
> For Consortium Member technical support, see
> <>
> To unsubscribe from this list send an email to users-
> unsubscribe at <mailto:unsubscribe at>
For Consortium Member technical support, see <>
To unsubscribe from this list send an email to users-unsubscribe at <mailto:users-unsubscribe at>

More information about the users mailing list