[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-dev
Subject:    Re: How can we help on https://git.shibboleth.net/view/?p=java-sp-server.git ?
From:       "Cantor, Scott via dev" <dev () shibboleth ! net>
Date:       2022-05-31 12:50:33
Message-ID: 56325189-538D-46CB-B244-4D16F8A30FBC () osu ! edu
[Download RAW message or body]

On 5/27/22, 1:52 PM, "Jason Pyeron" <jpyeron@pdinc.us> wrote:

> Regarding [1] and security thoughts
> 
> 1. there is no compelling reason today to not use mutual (2-way) authenticated TLS \
> as a transport.

There is a really big one, aside from just performamce, the need for configuring and \
managing that and having the right dependencies in place. The assumed model here is \
still localhost deployment alongside agents. We are hoping and expecting that the \
final product will be able to do more than that, but how far it scales is difficult \
to say.

On the Java side, I think TLS is a reasonable expectation as a feature. On the other \
side, the solution would be stunnel, there's absolutely zero chance we continue to \
link this code to OpenSSL (or anything else). There will be absolutely no \
dependencies beyond a C/C++ runtime in this build, whatever it takes. That is the \
most important consideration at this stage.

> 2. when possible messages/payloads should maintain nonrepudiation (e.g. a signature \
> wrapper)

Don't agree. For one thing I have no signature format to use (and again, no \
dependencies, that's a hard requirement), but even if I did, it would be a lot of \
work and be vulnerable to MITM attacks anyway. TLS is the way to go if it's not \
running over localhost.

Of course in the end the transport is going to be pluggable anyway.

-- Scott


-- 
To unsubscribe from this list send an email to dev-unsubscribe@shibboleth.net


[prev in list] [next in list] [prev in thread] [next in thread]