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 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 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 wrote:
>>
>>
>>
>>>
>>> On Jun 18, 2020, at 4:24 AM, Jakov Varenina
>>> 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
>>
>
