Hi Jake and all,
Great findings and analysis Jake! Thank you very much for you effort!
We haven't gone far with the implementation of the solution described in
the research paper. So it is a great that you have found alternative and
better solution, but it seems that the attachment with patch is missing
from you mail.
Also, we agree with your points that it is better to read certificate on
server side and forward it as a whole to the SecurityManager
authenticate, since it adds more benefit and flexibility to the users
than just having CN and SAN.
Could you please just clarify a bit more your opinion on this below?
> On Jun 19, 2020, at 2:53 PM, Jacob Barrett <jabarr...@vmware.com> wrote:
> ... 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..
If I correctly understood and we leave RMI out of the solution that
would mean one of the following scenarios:
1) Geode would have to use existing username/password authentication and
authorization feature just for RMI connections, and the new kind of
certificate auth for all other interfaces. This way user will still have
to handle usernames/passwords which we want to get rid of, and also this
would complicate a little bit more implementation of SecurityManager
interface (user would have to deal with both certificates and
username/passwords).
2) If geode doesn't use username/password feature and the certificate
based auth is enabled, then it will have to reject all RMI connections,
since the clients initiating those RMI connections cannot be properly
authenticated and authorized on the server side.
BRs/Jakov
On 22. 06. 2020. 23:11, Jacob Barrett wrote:
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
>>
>
