Max,
as i tried to explain in my last reply, my preferred API would be to
have a functional callback at the appropriate stage of the
connection establishment to check the source-ip address dynamically
and then proceed with connection establishment or reject it.
Cheers
Toerless
On Thu, Aug 08, 2019 at 11:27:56PM +0200, Max Franke wrote:
> <div dir='auto'><div>Hi Toerless,</div><div dir="auto"><br></div><div
> dir="auto">at the moment you could force your listener to only accept
> connections from specific IP addresses by setting a remoteEndpoint on the
> Preconnection before calling listen(). </div><div dir="auto">Though I
> agree that it might indeed be good idea to also make it possible to provide a
> blacklist of specific IPs from which you dont want accept
> connections.<br><div class="gmail_extra" dir="auto"><br></div><div
> class="gmail_extra" dir="auto">Best</div><div class="gmail_extra"
> dir="auto">Max</div><div class="gmail_extra" dir="auto"><br><div
> class="gmail_quote" dir="auto">Am 08.08.2019 21:31 schrieb Toerless Eckert
> <[email protected]>:<br type="attribution"><blockquote class="quote"
> style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p
> dir="ltr">Thanks Tommy,
> <br>
>
> <br>
> I couldn't quite figure out from the spec what context/parameters
> <br>
> would be made available to the callback.
> <br>
>
> <br>
> Also: i would be worried about not having the callback option for
> <br>
> the client IP address checking. Just think of all the apps
> <br>
> doing GeoBlocking (video streaming) or verifying client DNS
> <br>
> domain for list of subscribers (academic papers come to mind).
> <br>
> I don't think you always want to force the server software
> <br>
> developer to calculate such a long ACL upfront. It might be
> <br>
> preferred in high-performance cases, but the most simple server
> <br>
> would do this on-demand.
> <br>
>
> <br>
> Cheers
> <br>
> Toerless
> <br>
>
> <br>
> On Wed, Aug 07, 2019 at 02:43:35PM -0700, Tommy Pauly wrote:
> <br>
> > Hi Toerless,
> <br>
> >
> <br>
> > Thanks for the questions! Definitely an interesting topic.
> <br>
> >
> <br>
> > I think what you're trying to get at, checking the client's
> authentication properties on the server, is described here:
> https://tools.ietf.org/html/draft-ietf-taps-interface-04#section-5.3.2.
> <br>
> >
> <br>
> > o Trust verification callback: Invoked when a
> Remote Endpoint's
> <br>
> > trust must be validated before the
> handshake protocol can proceed.
> <br>
> >
> <br>
> > TrustCallback := NewCallback({
> <br>
> > // Handle trust, return the result
> <br>
> > })
> <br>
> >
> SecurityParameters.SetTrustVerificationCallback(trustCallback)
> <br>
> >
> <br>
> >
> <br>
> > The idea here is that when you configure TLS options on your Listener
> object, you can configure optional event callbacks to participate in the
> certificate checking, thus allowing the check to occur prior to the TLS
> handshake actually completing.
> <br>
> >
> <br>
> > In the Apple implementation, we do this with a call
> "sec_protocol_options_set_verify_block", documented here:
> <br>
> >
> <br>
> >
> https://developer.apple.com/documentation/security/2976289-sec_protocol_options_set_verify_?language=objc
> <br>
> >
> https://developer.apple.com/documentation/network/security_options?language=objc
> <br>
> >
> <br>
> > Related to this, we recently had an issue we were discussing around
> allowing the application to filter a connection prior to accepting TCP on a
> server, in the accept path
> (https://github.com/ietf-tapswg/api-drafts/issues/338). This type of event
> would *only* allow looking at the client IP address, and wouldn't help for
> looking at the TLS certificate. We determined that for the TCP case, there
> can often be a way to push down firewall type rules in the system, and doing
> this as a per-accept callback may not be the best model.
> <br>
> >
> <br>
> > Thanks,
> <br>
> > Tommy
> <br>
> >
> <br>
> > > On Aug 7, 2019, at 1:51 PM, Toerless Eckert <[email protected]>
> wrote:
> <br>
> > >
> <br>
> > > [ Sorry for being lazy and ask even though i haven't read all the
> documents.
> <br>
> > > If the question is answers by some existing text/thread, pls.
> let me know. ]
> <br>
> > >
> <br>
> > > Precursor question: Server for TCP connections wants to be able to
> <br>
> > > dynamically reject connection requests based on the clients
> connection
> <br>
> > > parameters, e.g.: client IP-address. Dynamic meaning that the server
> <br>
> > > should get a notification/callback, be able to examine the
> parameters
> <br>
> > > and decide. Aka: no predefined policy object that can not run server
> <br>
> > > code at the time of receiving the client connection request.
> <br>
> > >
> <br>
> > > I do not even remember wht the best current POSIX socket API is to
> do
> <br>
> > > this today. Traditionally, servers suck at this, because they use an
> <br>
> > > accept(), so the connection is established, and then they
> immediately
> <br>
> > > close the connection once they have retrieved the clients IP-address
> <br>
> > > (getpeername or the like).
> <br>
> > >
> <br>
> > > So, the actual question is pretty much the same except that i don't
> care
> <br>
> > > about the client IP-address but for TLS connections in the ability
> for
> <br>
> > > the client-side to examine the server certificate presented and the
> <br>
> > > server-side to examine the client-side cetificate presented - and in
> <br>
> > > both cases have the hook for this notification/callback early
> enough
> <br>
> > > in the sate machinery of the transport protocol that no unnecessary
> <br>
> > > steps are performed (e.g.: exactly NOT the above mentioned connect
> &
> <br>
> > > drop behavior).
> <br>
> > >
> <br>
> > > Thanks!
> <br>
> > > Toerless
> <br>
> > >
> <br>
> > > _______________________________________________
> <br>
> > > Taps mailing list
> <br>
> > > [email protected]
> <br>
> > > https://www.ietf.org/mailman/listinfo/taps
> <br>
> >
> <br>
>
> <br>
> --
> <br>
> ---
> <br>
> [email protected]
> <br>
>
> <br>
> _______________________________________________
> <br>
> Taps mailing list
> <br>
> [email protected]
> <br>
> https://www.ietf.org/mailman/listinfo/taps
> <br>
> </p>
> </blockquote></div><br></div></div></div>
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
