3 ms·
> Hence you can include with the app files a server certificate For more flexibility, you can include your own CA certificate, which you use to sign your serve
by rakoo 12y ago
> Hence you can include with the app files a server certificate
For more flexibility, you can include your own CA certificate, which you use to sign your servers' certificate, so that you can add/remove them without needing to update the app.
> I think it's highly unnecessary to have the overhead of certificate presentation, cipher negotiation
If you (as a user) are really strict about privacy/security, or if you exchange a lot of information with the server, the benefits of TLS (or any security scheme for that matter) will outweigh the drawbacks soon enough that you will not think of it as a problem.
> what is often as few as 40 bytes
Your credit card number is only 16 bytes, but I guess you want to securely transmit that :)
- thegeomaster 12y ago>For more flexibility, you can include your own CA certificate This would require the server to present a certificate to a client. With that, I might as well be creating a TLS clone. So I'd like to avoid that for the sake of simplicity, at least for the first versions. I'll see where it goes from there. >If you (as a user) are really strict about privacy/security, or if you exchange a lot of information with the server, the benefits of TLS (or any security scheme for that matter) will outweigh the drawbacks soon enough that you will not think of it as a problem. I was referring to cipher negotiation and certificate presentation, both of which, in my case, are in theory unnecessary to have security as strong as provided by TLS. >Your credit card number is only 16 bytes, but I guess you want to securely transmit that :) I never said I wanted to sacrifice security for the 40 bytes, I was just saying that the HTTP overhead and TLS overhead is really a lot, and if I can get away with a specialized protocol with a lower overhead, that would be even better :)