[Twisted-Python] Re: cred and stateless protocols

[Manlio Perillo]

Phil Mayers ha scritto:
> [...]
> 
> You can do that now if you want. But the hardware is expensive. Frankly,
> I think a local software store with key is fine.
> 
> But the important thing is to use SSL and server certs. The client certs
> are just a nice-to-have.
> 

One more thing.
Actually, if I'm right, web servers and UAs like Apache and Mozilla only
do certificate *verification*, without identification/authorization.

I'm interested in the latter case.

>>> an "Authorization: GoogleAuth THETOKEN" header. 
>>
>> And this header should be supplied for every successive requests (like
>> cookies)?
> 
> Yes, avoiding the need for an extra round-trip per request.
> 

But in this way isn't it unsecure to man in the middle attacks?


>  [...]
> 
>>
>>> You might ponder that Google separated out auth and sessions
>>> even in their engineering compromise.
>>>
>>> Note that the above refers to the non-browser API. Presumably the
>>> browser API will use a passport-alike 302+cookie.
>>>
>>> For open source examples, see PubCookie.
>>>
>>
>> Thanks for the link.
>> I have not read the source, but the "granting cookie" what type of
>> informations contains to be sure that the UA is the "right" one?
> 
> I haven't used it, I just know it's generally well thought of.
> 

The thing that is not clear to me is if every resource requires 3 pair
of request/response (4 for the first time when login).

And what about nevow guard?
I have searched some documentation but with no results.

> [...]
>>
>>     def datagramReceived(self, data, (host, port)):
>>         context = self.users.setdefault(host, Context())
>>         response = context.handle(data)
>>         self.transport.write(data, (host, port))
>>
>>
>> Where the Context class keep an internal state, like IMAP.
> 
> That is phenomenally insecure
> 

Sorry, I just forget to add the port too!

>  1. You're using just the IP and not the IP+port, which means 2 users
> behind the same NAT will be unable to simultaneously use your service,
> or will see each others data.
> 

Ok.

>  2. Since it's UDP it's trivially forged, so unless your context.handle
> FURTHER authenticates the data (via e.g. HMAC and key agreement) it's
> basically open to the world
> 

Of course some type of authentication is required.
The idea is to use the context like a Twisted protocol class for TCP.

>  3. You're creating a new context for the 1st packet from each IP, so I
> can trivially send hundreds of thousands of packets to your service with
> forged source addresses and exhaust the CPU and memory resources of your
> server.
> 

This is a problem, but it can occurs for TCP too.

> At ABSOLUTE MINIMUM a UDP protocol must force the client to round-trip
> the first packet using minimal CPU resources possible to at least ensure
> it's not a source-spoofing DDoS.
> 

Ok, thanks.

> # WARNING WARNING WARNING DO NOT USE INSECURE IN MANY WAYS
> # I strongly suggest the use of TCP or existing secure UDP
> # protocols such as Q2Q

> [...]

Thanks for the idea.

About Q2Q: I got no entry about it in wikipedia...
Is this another twisted/divmod "private" protocols?



Thanks and regards  Manlio Perillo