Just checking, is anyone familiar enough with SSL to comment on the proposed change?
Anthony > On Oct 29, 2019, at 2:44 AM, Mario Ivanac <mario.iva...@est.tech> wrote: > > Hi, > > We are trying to find a solution for an situation we have. Below is the > explanation of the issue, as well as a proposed way forward. We would > appreciate comments from the community regarding this approach. Also, > suggestions for a different approach to solve this issue would be welcome. > > The situation is the following: when SSL is enabled, we would like to use > multiple certificates in locators and servers: one certificate for > communication inside one geographical site, and another for the communication > happening between geographical sites. The approach we took is to use the > default SSL context and implement our own Java Security Provider. > > The client side can, from the security provider, easily distinguish which > certificate to use (just check if you are initiating a connection towards an > IP listed in gemfire.remote-locators). The thing we are missing is a criteria > based on which we can choose the certificate on the server side of the > connection. Explanation: Once the handshake starts, a ClientHello message is > sent from the peer acting as a client in that connection (be it a geode > server or a geode locator). When the ClientHello is received on the server > side, we can’t always read the real originating IP (keeping the originating > IP is sometimes not possible in cloud native environments), so we can’t be > sure whether the message originated from the same geographical site or from > another. We are left only with the information inside the ClientHello > message. The default ClientHello message doesn’t contain information based on > which we can conclude which site the message came from and which certificate > to use. > > Our proposal is to add the server_name extension in the ClientHello message. > The content of that extension would be the distributed system ID of the site > where the ClientHello originated. This way we could compare the distributed > system ID in the ClientHello message with the ID of the site where the > message is received. > > One issue with this approach is that the usage of the extension wouldn’t be > completely in line with the RFC<https://tools.ietf.org/html/rfc6066#page-6> > description: we would be inserting client information instead of the targeted > server name. Still, since this extension is otherwise of no use in Geode, and > this approach doesn’t present a security risk (we would be sharing the > distributed system ID, which doesn’t look dangerous), we see this as a > potential way to go. > > >
