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).
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.
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.
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.
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.
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!
Gr. Sim
Apache river: The Data is the Code! (and vice-versa)
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397
