Re: [Taps] TAPS (secure) connection maangement Q

[Toerless Eckert <[e-mail]>]

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().&nbsp;</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 &lt;[e-mail]&gt;:<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>
> &nbsp;&nbsp;&nbsp; Toerless
> <br>
> 
> <br>
> On Wed, Aug 07, 2019 at 02:43:35PM -0700, Tommy Pauly wrote:
> <br>
> &gt; Hi Toerless,
> <br>
> &gt; 
> <br>
> &gt; Thanks for the questions! Definitely an interesting topic.
> <br>
> &gt; 
> <br>
> &gt; 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>
> &gt; 
> <br>
> &gt;&nbsp;&nbsp;&nbsp; o&nbsp; Trust verification callback: Invoked when a Remote Endpoint's
> <br>
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; trust must be validated before the handshake protocol can proceed.
> <br>
> &gt; 
> <br>
> &gt;&nbsp;&nbsp;&nbsp; TrustCallback := NewCallback({
> <br>
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // Handle trust, return the result
> <br>
> &gt;&nbsp;&nbsp;&nbsp; })
> <br>
> &gt;&nbsp;&nbsp;&nbsp; SecurityParameters.SetTrustVerificationCallback(trustCallback)
> <br>
> &gt; 
> <br>
> &gt; 
> <br>
> &gt; 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>
> &gt; 
> <br>
> &gt; In the Apple implementation, we do this with a call "sec_protocol_options_set_verify_block", documented here:
> <br>
> &gt; 
> <br>
> &gt; https://developer.apple.com/documentation/security/2976289-sec_protocol_options_set_verify_?language=objc
> <br>
> &gt; https://developer.apple.com/documentation/network/security_options?language=objc
> <br>
> &gt; 
> <br>
> &gt; 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>
> &gt; 
> <br>
> &gt; Thanks,
> <br>
> &gt; Tommy
> <br>
> &gt; 
> <br>
> &gt; &gt; On Aug 7, 2019, at 1:51 PM, Toerless Eckert &lt;[e-mail]&gt; wrote:
> <br>
> &gt; &gt; 
> <br>
> &gt; &gt; [ Sorry for being lazy and ask even though i haven't read all the documents.
> <br>
> &gt; &gt;&nbsp; If the question is answers by some existing text/thread, pls. let me know. ]
> <br>
> &gt; &gt; 
> <br>
> &gt; &gt; Precursor question: Server for TCP connections wants to be able to
> <br>
> &gt; &gt; dynamically reject connection requests based on the clients connection
> <br>
> &gt; &gt; parameters, e.g.: client IP-address. Dynamic meaning that the server
> <br>
> &gt; &gt; should get a notification/callback, be able to examine the parameters
> <br>
> &gt; &gt; and decide. Aka: no predefined policy object that can not run server
> <br>
> &gt; &gt; code at the time of&nbsp; receiving the client connection request.
> <br>
> &gt; &gt; 
> <br>
> &gt; &gt; I do not even remember wht the best current POSIX socket API is to do
> <br>
> &gt; &gt; this today. Traditionally, servers suck at this, because they use an
> <br>
> &gt; &gt; accept(), so the connection is established, and then they immediately
> <br>
> &gt; &gt; close the connection once they have retrieved the clients IP-address
> <br>
> &gt; &gt; (getpeername or the like).
> <br>
> &gt; &gt; 
> <br>
> &gt; &gt; So, the actual question is pretty much the same except that i don't care
> <br>
> &gt; &gt; about the client IP-address but for TLS connections in the ability for
> <br>
> &gt; &gt; the client-side to examine the server certificate presented and the
> <br>
> &gt; &gt; server-side to examine the client-side cetificate presented - and in
> <br>
> &gt; &gt; both cases have the hook for this notification/callback early enough 
> <br>
> &gt; &gt; in the sate machinery of the transport protocol that no unnecessary
> <br>
> &gt; &gt; steps are performed (e.g.: exactly NOT the above mentioned connect &amp;
> <br>
> &gt; &gt; drop behavior).
> <br>
> &gt; &gt; 
> <br>
> &gt; &gt; Thanks!
> <br>
> &gt; &gt;&nbsp;&nbsp;&nbsp; Toerless
> <br>
> &gt; &gt; 
> <br>
> &gt; &gt; _______________________________________________
> <br>
> &gt; &gt; Taps mailing list
> <br>
> &gt; &gt; [e-mail]
> <br>
> &gt; &gt; https://www.ietf.org/mailman/listinfo/taps
> <br>
> &gt; 
> <br>
> 
> <br>
> -- 
> <br>
> ---
> <br>
> [e-mail]
> <br>
> 
> <br>
> _______________________________________________
> <br>
> Taps mailing list
> <br>
> [e-mail]
> <br>
> https://www.ietf.org/mailman/listinfo/taps
> <br>
> </p>
> </blockquote></div><br></div></div></div>