I went on a little journey to see if it was possible and it looks promising. I was able to get access to the SSLSocket and thus the SSLContext.
Proof of concept patch attached. > On Jun 19, 2020, at 2:53 PM, Jacob Barrett <jabarr...@vmware.com> wrote: > > So I can see why this research paper was so bleak about the options in trying > to get the SSL certificate for the current connection being serviced. As they > discovered the accept loop in OpenJDK’s (and older Oracle implementations) > immediately fires the RMI operation to a thread pool after connected. This is > after SSLSocket would have would’ve done the handshake and been passed to any > of our validation callbacks so stashing anything in a thread local storage is > dead. > > Good news is deep in the sun.rmi.transport.tcp.TCPTransport there is a > ThreadLocal<ConnectionHandler> that has the socket used to establish the > connection and this thread local is set before each invocation of an RMI > operation. The bad news is that it's private on an internal class. I think > this is where the age of the research is in our favor. Back when I think it > was writing we didn’t have OpenJDK. We had Oracle, IBM, and a few others. Now > with everything pretty much converging on OpenJDK I don’t believe it as as > nasty to go poke at this internal using reflection. I think it is less dirty > then their nasty trick of utilizing the IPv6 address as a unique identifier > in a custom Socket. > > Once we have the SSLSocket for this connection then we are golden. From there > you have public API access to the SSLSession. > > Looking at the OpenJDK source this class has largely been unchanged since its > initial import into the repo in 2007. Most importantly the private member in > question has been and its sill available in all versions of OpenJDK. Sure > this limits us to OpenJDK support for certificate based authentication by SSL > handshake via RMI but in Geode that’s really only gfsh. This is a really > small surface area. With the focus being on converting gfsh activities into > REST APIs this surface area is shrinking. Personally I would be inclined to > leave RMI out of the solution initially. Second I would use this private > variable to compete the support in OpenJDK. > > -Jake > > >> On Jun 19, 2020, at 11:14 AM, Jacob Barrett <jabarr...@vmware.com> wrote: >> >> >> >>> >>> On Jun 18, 2020, at 4:24 AM, Jakov Varenina >>> <jakov.varen...@est.tech<mailto:jakov.varen...@est.tech>> wrote: >>> >>> In order to completely remove the need for username/password, it is >>> required that we implement this new kind of authorization on *all* geode >>> interfaces/components (cluster, gateway, web, jmx, locator, server). The >>> reason why we didn't have any progress is because we faced major obstacle >>> during development when we tried to retrieve clients certificate from RMI >>> connections (e.g. jmx connections). It seems there are no easy/nice way to >>> retrieve it, and what we came up so far is following: >>> >>> 1) We have found some possible "hack solution" that could be implemented >>> and it is described in the following paper >>> (https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.224.2915%26rep%3Drep1%26type%3Dpdf&data=02%7C01%7Cjabarrett%40vmware.com%7Cb850f9bde4674352e4a908d8149b3ad0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637282004231487337&sdata=SbJiZKJxsJ3lTmKFVFIPRNzVO2tmc4w817Asbra5lR4%3D&reserved=0). >>> We have started to work on the prototype that will implement this solution. >> >> Wow, that is a hack. Have you found any implementation of this solution. >> There doesn’t appear to be a repository listed. There also doesn’t appear to >> be a publish date on this document. The most recent references are from >> 2010. I wonder if things are better now. I am going to poke at the Java >> source code a bit and report back. >> >> Would your needs be dependent on Java 8? If we found a solution that only >> worked say with java 12, would that work? >> >> -Jake >> >
