AW: back-channel on front-channel port

Tue Jun 29 07:54:26 UTC 2021

Hi Nate,

thanks for the background. I currently use Apache as AJP-reverse proxy and "SSLVerifyClient optional_no_ca". [1] suggests that this should work but "will cause problems for some SPs".
You suggest that it is advisable to configure client authentication to add an extra layer of security which I fully understand. Apache mod_ssl supports enabling client authentication only for some Locations which would suggest that adding such a configuration would remove the requirement for an additional vhost/port. What I did not understand because of my missing understanding of the TLS protocol was, that to support this feature a TLS renegotiation is required. I found this information in [2]. The missing puzzle piece was [3] which states "The code as it stands does not generally support TLS Renegotiation, which is most commonly encountered when using a virtual host that applies client TLS to only a subset of paths and not the host as a whole. ". 
That means that while Apache would allow enabling client authentication for only some part of the vhost, the shibboleth client would not support this.
Therefore it is currently my plan to use two apache vhosts. One for front- and back-channel. To prevent the need for another port I currently plan to differentiate on the vhost hostname and not the vhost port. Do you know if the shibboleth client code which does not support TLS Renegotiation will support SNI?

[1] https://wiki.shibboleth.net/confluence/display/IDP4/SecurityAndNetworking#SecurityAndNetworking-Apache
[2] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslrenegbuffersize
[3] https://wiki.shibboleth.net/confluence/display/IDP4/HttpClientConfiguration#5580440395da55d2d5dc42eca5b087bed460c8bc

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
http://www.hrz.tu-darmstadt.de/

> -----Ursprüngliche Nachricht-----
> Von: users <users-bounces at shibboleth.net> Im Auftrag von Nate
> Klingenstein
> Gesendet: Dienstag, 29. Juni 2021 08:09
> An: Shib Users <users at shibboleth.net>
> Betreff: RE: back-channel on front-channel port
> 
> Clemens,
> 
> 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,
> Nate.
> 
> --------
> Signet, Inc.
> The Art of Access ®
> 
> https://www.signet.id
> 
> -----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
> http://www.hrz.tu-darmstadt.de <http://www.hrz.tu-darmstadt.de>/
> 
> > -----Ursprüngliche Nachricht-----
> > Von: users <users-bounces at shibboleth.net <mailto:users-
> bounces at shibboleth.net>> Im Auftrag von Cantor, Scott
> > Gesendet: Montag, 28. Juni 2021 16:34
> > An: Shib Users <users at shibboleth.net <mailto:users at shibboleth.net>>
> > 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
> > https://wiki.shibboleth.net/confluence/x/coFAAg
> <https://wiki.shibboleth.net/confluence/x/coFAAg>
> > To unsubscribe from this list send an email to users-
> > unsubscribe at shibboleth.net <mailto:unsubscribe at shibboleth.net>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> <https://wiki.shibboleth.net/confluence/x/coFAAg>
> To unsubscribe from this list send an email to users-
> unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net>
> 
> 
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to users-
> unsubscribe at shibboleth.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6377 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20210629/7d3f1033/attachment.p7s>