Sim IJskes - QCG wrote:
Peter Firmstone wrote:
Exactly, you cannot provide proxies in the wild without some kind of
verification. Thats why i keep returning to things analogous to
tunnels/VPNs etc. Because i want a TLS session end to end.
IPSec (VPN) packets cannot be mangled, it breaks the checksum, so the
IPSec packet is wrapped in another packet that gets mangled, this
provides the encryption end to end, unfortunately it requires low
level Kernel support as it's below the TCP/IP Layer, so it isn't
available without network admin intervention.
We have to be careful to avoid a man in the middle with our Relay,
see below I have some more thoughts.
By providing a transparent packet relay, we can still provide for an
end-to-end TLS session, implemented with the
javax.net.ssl.SSLEngine.{wrap,unwrap} functions. And conceptually i
still see this as tunneled JERI session. And because the session is
running end-to-end, the change of a MITM is equivalent to other
solutions. The javax.net.ssl.SSLSession. getPeerPrincipal() provides
us with the Principals needed for our JERI security.
The JERI Relay is only a public reachable bi-directional mailbox for
JERI packets/messages.
Perhaps JR can provide these functions:
2. Keeps a line of communication open to the private Service
utilising a heartbeat
This is not needed, a connection to a JR is on a polling basis,
initiated from the service (acting as a client from an RPC
perspective). (think XMPP, XEP-0124 BOSH).
Ok, so if it doesn't poll (empty packet) within a certain time, it's
lease expires?
3. Read's ByteBuffer's from a Socket Channel, and write it's content
to another Socket Channel without decrypting it. If it isn't
visible to the Relay and the Server and client can verify the JRS
code, then there is potential there to trust the Relay.
There is no trust of the Relay. End to end TLS session is all the
security we need. If you want to relay my service, be my guest. You
cannot inspect, you cannot intercept.
That's much simpler, use authentication instead to avoid the MIM.
4. SSL Handshake: Not sure about how the handshake process from
actual client to private service will handle the redirect.
There is no redirect. The test used in HTTPS where the CN is compared
with the hostname is outside the scope of the TLS protocol IMHO.
Ok, good that solves that problem.
Perhaps the BasicJeriExporter can inspect the IP Address, and if it
lies within a private range, check a system property to determine if
JR Services are to be utilised?
Can i reserve judgement on that? I cannot oversee the effect right now.
Sure.
JR could be looked up just like any other service, it only executes
local code, doesn't need to know the details but can be trusted
enough by the Service and client not to peek at the details.
Indeed, only local code, and it may peek at the stream just like any
other router.
Ok.
JR probably needs to be identified by a public domain certificate,
although this is a weak defence (DNS cache poisoning), it adds
another layer.
No, no, no. I can not cooporate with an implementation where we
include the requirement that one MUST use a domain certificate. We
want to free ourselfs of the network admin, but chain ourselfs to a
costly certificate authority?
I want to spray the internet with certificates, and cannot find the
money to fund that!
Just checking your paying attention ; ) good point, just use
authentication! Actually having thought about this a little more,
allowing public domain certificates would probably weaken security, as
some clients would rely on this flawed mechanism (exposing us to DNS
cache poisoning). Even though it checks the box of the marketing manager!
Gr. Sim
Apache river: The Data is the Code! (and vice-versa)
Nice catch phrase. All about getting back to the original concepts
around Objects.
Cheers,
Peter.
