[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    Re: [e-lang] Intra-host CapTP (was E language over I2P)
From:       Kevin Reid <kpreid () mac ! com>
Date:       2008-02-29 21:31:54
Message-ID: D4992E24-BF27-4122-9D6F-6498426061A0 () mac ! com
[Download RAW message or body]

On Feb 29, 2008, at 15:13, Jack Lloyd wrote:

> I'd say making the distinction between localhost and not isn't a good
> tradeoff here regardless: in return for saving a few cycles (AES is
> pretty darn fast), you leave open the possibility that a vat could be
> tricked into not using encryption when it should. For instance,
> consider two malicious proxies that are on two different machines,
> that proxy for (and record the conversation between) a vat on another
> machine:
>
> Machine 1                                   Machine 2
>
>   Vat 1                                       Vat 2
>    ^                                            ^
>    | (local domain socket)                      | (domain socket)
>    v                                            v
>   Proxy 1   <-------------- TCP -----------> Proxy 2
>
> Since the TLS key exchange is still secure (perhaps at least; making
> the kex secure against MITM attacks is a different issue) and the
> messages are MACed, the proxies cannot modify the conversation but
> they can observe it (which would seem to be enough to cause
> substantial damage in many cases). Each vat think it is talking
> to another vat on it's local machine, so it thinks NONE is safe
> to use when it's actually not.

Whoops. You're right. It's only safe to use unencrypted communication  
when it can be verified that the /channel/ is reliable.

It doesn't even need two machines: VatA has a reference to something  
in same-machine VatC. VatA passes it to VatB, including as the search- 
path a socket to its own proxy for a socket to VatC. Given that  
(something in) VatB has some prior relationship with VatC, this  
reveals information to VatA that it should not have.

> I don't know the details of the vat communication protocol, so that
> particular method might not work at all, but in general it seems like
> this is creating complexity in return for very little gain. (There's
> my $.02)

The goal is to make intra-machine communication cheap - not  
unreasonably more expensive than other forms of IPC (or, ideally,  
inter-thread communication).

It looks to me like encryption can only be dispensed with when it is  
known that the socket (or whatever) is /directly connected to/ the  
process which knows the target vat's private key. I can't think of a  
way to implement this on unixoids outside of the degenerate case  
where the other end is in the same process --

Ah. Communicating through unix socket files which are only writable  
by the user (since all processes of a user are mutually vulnerable,  
you already lose if an impersonator is running with your uid). Which  
latter is actually not too bad, though it doesn't work between unix  
users. Okay. Might be a bit fragile, though.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>


_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
[prev in list] [next in list] [prev in thread] [next in thread]