1

What are the downsides of not adhering to TLS, eg, directly using encryption algorithms (2048-bit RSA, 128-bit AES both with proper padding) provided by SSL library to generate keys, encrypt, use proprietary "certificates" and proprietary protocol in general. First thing that comes to mind is that this will prevent downgrade attacks, and allow developer to implement mechanism against timing attacks, my main reasoning here is that to be sure that library won't do anything dangerous behind the scenes.

Bleeding Alice
  • 29
  • 4
  • 1
    The question is not fully clear. Are you essentially asking what the downsides are if you implement a proper authentication, key exchange, encryption and MAC in a similar secure way as TLS but not exactly like in TLS? I.e. keep all ideas but change the protocol slightly? And what downgrade and timings attacks you want to prevent which are not fixed in latest TLS versions or which only depend on bad implementation of cryptographic algorithms independent from TLS? – Steffen Ullrich Jul 19 '17 at 17:52
  • 1
    A rule of thumb: don't roll your own crypto: https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own – Crypt32 Jul 19 '17 at 18:53
  • Crypto is hard to do right. If you do your own you'll likely screw it up. Use something that is reviewed and tested. That doesn't guarantee there won't be mistakes, but it does make it likely there will be fewer for you to deal with. – Swashbuckler Jul 19 '17 at 18:55
  • SSH is a protocol that uses similar algorithms but is not SSL. It has had some subtle flaws (e.g. [this](https://www.coresecurity.com/content/ssh-protocol-15-session-key-recovery-vulnerability)) – paj28 Jul 19 '17 at 19:16
  • Are you willing to write your own client? A web browser will not handle your special protocol. Where and how will you establish trust, without SSL certificates. Also, I echo @SteffenUllrich; it's not clear what you mean to do and why... – Jedi Jul 19 '17 at 20:31
  • @Jedi i am aware that it will be incompatible with real SSL, only our own app will use this protocol, certificates will be issued by our own server as well – Bleeding Alice Jul 20 '17 at 06:48
  • @Crypt32 im not rolling my own crypto, just protocols – Bleeding Alice Jul 20 '17 at 06:49

1 Answers1

3

The biggest downside is that you're expecting that because you're writing something smaller, it will also be safer. In reality, this is really hard to do.

Given that you must control both ends of the connection in order to even consider implementing a custom protocol in place of TLS, there are other way you can increase the security and reduce the attack surface without going through the exercise of inventing and implementing a custom protocol and hoping it's safer.

For instance:

You want to prevent downgrade attacks? Disable everything except for TLS v1.2 on your servers and clients.

You want to ensure only strong cipher suites are used? Disable anything except for your AEAD cipher suites.

You have lots of options when using existing TLS libraries to lock them down and harden them, and even with all of their warts, they've undergone far more analysis than a custom protocol you build ever would. You're better off not re-implementing the wheel, but instead simply taking advantage of your opportunity to configure TLS as securely as possible.

Xander
  • 35,525
  • 27
  • 113
  • 141
  • and how will i be sure that disabling actually means disabling and it is not just hint or consideration to api ? – Bleeding Alice Jul 20 '17 at 06:50
  • @KolibriOS The best way would be by testing. Make sure it won't allow you to negotiate things you've turned off. It isn't foolproof, but the risk is tiny compared to the risk of introducing security flaws in a custom protocol design and implementation. – Xander Jul 20 '17 at 12:50