Re: [9fans] using tls-psk cipher suits vs roll our own handshake

> 5) seems to much effort to do right/securely, no? kind of. one would indeed need to authenticate the messages somehow, and maintain lists of usefull cipher suits ect. which basically is what tls already does. right now, i'm kind of in favour for using tls-psk (rfc4279) even if it might seem

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

no. the "shared secret from the authentication process" refers to the random key generated by the AS (and transported to both the server and client in tickets that are encrypted with the servers/clients key). the situation is that server and client already authenticated each other and have a

[9fans] using tls-psk cipher suits vs roll our own handshake

plan9 currently uses the shared secret from the authentication process with ssl and rc4 cipher for encrypting traffic for exportfs and the cpu services (pushssl()). the cipher can be changed by the client by providing command line parameters, tho there is no real negotiation going on. if the

Re: [9fans] using tls-psk cipher suits vs roll our own handshake

5) seems to much effort to do right/securely, no? On Thu, Dec 24, 2015 at 4:45 PM, wrote: > plan9 currently uses the shared secret from the authentication > process with ssl and rc4 cipher for encrypting traffic for > exportfs and the cpu services (pushssl()). the