[haiku-commits] Re: haiku: hrev50368 - src/kits/network/libnetapi headers/os/net

  • From: "Mark Hellegers" <mark@xxxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Fri, 24 Jun 2016 00:11:21 +0200 CEST

Hi Mark,

On 22/06/2016 22:37, Mark Hellegers wrote:
But as to the concerns about the patch:
The hostname is used in the application layer, but that does not 
make 
it an application concern. It is a network address and I see no 
problem 
with storing it at the internet layer in BNetworkAddress. It 
already 
gets it anyway, we just didn't store it before. There was even 
already 
a function to retrieve the hostname in BNetworkAddres. It simply 
was 
not implemented.

It's an application concern because the application knows how it 
should
be used. It should be the application's decision whether to send 
along
the hostname for server name indication. It shouldn't depend on 
whether
I happened to construct the BNetworkAddress with a string hostname or
not. Indeed it's perfectly possible to construct a BNetworkAddress 
with
an IP address. With this interface, it's impossible to use TLS SNI 
with
a BNetworkAddress constructed this way.

The hostname, and how this plays a part in TLS server name 
indication,
is the concern of the higher level protocol, TLS. The network layer
doesn't care about what hostname the network address sprung from; all 
it
cares about is the IP address to connect to.

What was a fairly simple wrapper around a socket address has now 
become
a socket address plus a hostname which may or may not be present
depending on how it was constructed. It violates the single
responsibility principle.

I'm not sure what you mean by the single responsibility principle, but 
I understand your other points.
To me that is the tradeoff to make. If you want to use TLS SNI, make 
sure you create a BNetworkAddress with the hostname set. It seems 
logical to me that if you need to use TLS SNI to connect to an address, 
you know the host. Might as well use it to construct the 
BNetworkAddress and let the system take care of the details for you.
As far as I can see, the whole of TLS is implemented inside 
BSecureSocket. You can't get at it outside of this class. If you want 
more control, you need to call OpenSSL directly.
 
Also, it seems awkward to force the caller to call an extra 
function 
simply to set the hostname while BNetworkAddress seems perfectly 
capable of holding that information. I would think that encourages 
buggy code by applications forgetting to set it, while it is now 
automatic as long as BNetworkAddress is called with a hostname.

The converse of this is that it's now forced upon the application
whether it wants it or not. An application now has to jump through 
hoops
to disable SNI or if they want to use it with a socket address 
they've
resolved by other means.

That's true, but looking at the current implementation of 
BSecureSocket, it does not give you any control at all.  If the 
intention is to give this kind of control to the developer then I agree 
that my implementation is flawed, but if it is not, then I think it is 
fair to enable it automatically as that is what is expected in most 
cases. Disabling it would be exceptional.

Kind regards,

Mark

--
Spangalese for beginners

`Halley mak ranfuer.'
`Your infant has swallowed my grenade.'



Other related posts: