0

Is it possible to have a cut down implementation of TLS , where we just presume the server we are connecting to is trusted - after the server sends its certificate, can we bypass verification of this and do away with any further processing , and get right into standard http ? Is using public key encryption something that is absolutely necessary , or can it be skipped ?

Rewording my question.

Is it possible to write a tls engine by skipping the need to use RSA public key code ?, or Can a client notify the server during the handshake that it just requires the severs certificate info, company name, expiry dates and requests the secret cipher key to be sent in plain text.

2 Answers2

0

Skipping something in a protocol I don't fully understand is generally a bad idea. Only steps marked as optional in the RFC can be safely skipped. Therefore if you don't plan to use client-side certificate based authentication you can skip it.

However what you can do however is limit the number of variations in your implementation. This means support only one TLS version (e.g. TLS 1.2) and support only one dedicated cipher suite.

Anyway the pitfalls when implementing TLS are so numerous that I recommend you to use an existing implementation (e.g. implementing in a way that does not allow side channel attacks is not that simple and requires knowledge on that topic). There are other implementations beside OpenSSL with a much smaller footprint.

BTW: If you can presume the connection is trusted you don't need TLS. If you need TLS it should be a secure.

Robert
  • 39,162
  • 17
  • 99
  • 152
0

where we just presume the server we are connecting to is trusted - after the server sends its certificate, can we bypass verification of this and do away with any further processing

The point of verification is less to find out if the server is trusted, but more that you are actually talking to the server you expect to. If you omit this step you are open to man-in-the-middle attacks.

But, TLS is a very flexible protocol and there are actually ways to use anonymous authentication or a shared secret with TLS and thus skip usage of certificates. Of course in this case you would need to have some other way to validate the server, because otherwise you would be still open to man-in-the-middle-attacks. And because this use case is mostly not relevant for the common usage on the internet it is usually not implemented inside the browsers.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • The server I am connecting to is on our intranet- so it's trusted.. I have the job of implementing tls from the RFCs ( no libs, openssl etc ) - most of the work has been done, excluding public key parts - I want to verify that what I have so far is compliant, without having to first finish PK etc. –  Mar 15 '15 at 10:04
  • Again, it is not the question if the server is trusted, but how you can be sure to talk to the correct server at all. I don't know about your local network, but in lots of local networks it is possible to mount DHCP, DNS or ARP spoofing attacks and thus redirect the traffic. This makes it possible to mount a man-in-the-middle attack. If everything is so trusted then why do you use TLS at all? – Steffen Ullrich Mar 15 '15 at 10:08
  • To verify what you've implemented so far you would need a client which is willing to use anonymous authorization. OpenSSL command line tools can do this, browsers usually don't. – Steffen Ullrich Mar 15 '15 at 10:16
  • Our network is trusted - but eventually our tls implementation will have to run on the public internet. I've broken the project up into two parts - ciphers, digests, handshakes, certificate processing -- and the final part the key exchange and connection complete.. - The first part I think is correct - and I'd like to check this without having to do the second part –  Mar 15 '15 at 12:16
  • In this case it would be sufficient to test it on localhost, which is probably more trusted than any LAN ever can be. And it simplifies the test setup if you can run client and server on the same machine. Maybe you should reword your question, because your target is obviously not to implement an incomplete TLS stack but to test a still incomplete stack. – Steffen Ullrich Mar 15 '15 at 12:46