Handle HTTPS and HTTP to same IIS Web Site

Peter Schober peter.schober at univie.ac.at
Wed Jan 31 06:31:56 EST 2018


* Alexander F. French <Alexander.F.French at dartmouth.edu> [2018-01-30 19:22]:
> Peter Schober responded to Alex:
> > Maybe re-think your troubleshooting methods to avoid having to run a server that way?
> > What is it you need from traffic-snooping you can't get from simply tuning log levels? Esp if you're snooping only your > own traffic?
> 
> With the semi-packaged application I primarily support and integrate
> with, there have been an unfortunate number of times in the last few
> years when thorny problems have involved needing to look in detail
> at network traffic and Windows ProcMon activity to prove to vendors
> that their logging is inadequate or just plain incorrect.

Since this is the Shibboleth mailing list the only thing of relevance
here is Shibboleth behaviour and debugging of (mainly) SAML protocol
messages. And all of the details you'D need to debug issues here can
be logged by the Shibboleth software (and sometimes web server
software).
So claiming you need to break or avoid TLS to the server is silly, IMO.

If you're talking about other aspects of your application stack, well,
then this has nothing to do with this list.

> Since we do SSL-offload at our load balancer, connecting directly to
> the host via SSL is introducing different details (from the servers
> point of view) during troubleshooting.

Seems to me the opposite is the case, as your own question here indicates:
By insisting to take a route to the service that's guaranteed to be
different than taken by those having issues you're in fact making sure
that you're introducing "different details" yourself. Taking the same
approach/route as subjects using the system on the other hand would
not.  But this is purely academic, of course.

-peter


More information about the users mailing list