A few tips: 1. The tool "openssl s_client" (with appropriate command line options) can be used (on a PC) to figure out which SSL/TLS options and variations a server is using, this may or may not be easier than waiting for an answer from vertx2. I would link to the online documentation, but it is down today. 2. The SSL/TLS protocols are documented in a number of RFCs. There is one main RFC for each SSL/TLS protocol version (SSL 3.0, TLS 1.0==SSL3.1, TLS 1.1==SSL3.2, TLS 1.2==SSL3.3), then there are a number of additional RFCs listing various standalone additions/extensions, such as additional choices for the algorithm numbers, and workaround for various issues. V.D. already provided a link to the TLS 1.2 RFC. 3. If you are making an embedded client that will talk only to one server model (as I understand your description), you can reduce your embedded implementation to only implement a single strong algorithm set for the latest SSL/TLS protocol version supported by that server. This will eliminate a lot of code in any SSL/TLS library. 4. There are available SSL/TLS libraries that are designed specifically for embedded systems. One such library (which I have not studied or tested, only heard of) is MatrixSSL. P.S. When I write that TLS 1.2==SSL3.3 etc., I mean that those protocols are named e.g. "TLS 1.2", but transmit a protocol version number such as 3.3 to indicate that they are more recent than Netscape SSL 3.0 . P.P.S. If you try to implement SSL/TLS yourself, note that skipping even the slightest detail from the specification (such as testing that some byte has the exact value it always has) can ruin the security. And skipping even the slightest extra security precaution discovered over the years by experts will also ruin the security. And doing stuff in new ways that others have never done might ruin the security in ways that others have never experienced. On 17/08/2015 07:55, Ajay Garg wrote: > Hi Viktor. > > Thanks for the reply. > > Yes, we need our (embedded-)clients to talk to our TLS-server. > > We are using Vertx2 as our server. > Its SSL-support APIs are in "SSLSupport" class at > http://vertx.io/vertx2/api/java/index.html > > Going by the APIs, it is not exactly clear what TLS-Algorithm and > Cipher-Suites are used in Vertx2 (I have put an email on the Vertx2 > mailing-list with this query, will let know as soon as I have some > answers). > > > > So, in the interim, I will be grateful if you guys could let us know > the generic native SSL-signalling steps (if at all there are any steps > that are independent of the TLS-Algorithm and Cipher-Suite). > > I know I sound incredibly clueless, kindly bear with me ... > > > Thanks and Regards, > Ajay > > On Sun, Aug 16, 2015 at 11:08 PM, Viktor Dukhovni > <openssl-users at dukhovni.org <mailto:openssl-users at dukhovni.org>> wrote: > > On Sun, Aug 16, 2015 at 02:44:54PM +0530, Ajay Garg wrote: > > > We wish to exhange data over sockets in embedded-environments, and > > unfortunately can't afford to use the de-facto openssl > implementation, > > which I believe uses dynamic memory allocations/deallocations in > its code > > (we intend to deploy our solution using bare-metal C, in > environments where > > even no RTOS are available). > > Why do you want to use TLS? Is this a closed communication protocol > only betweent these devices? Or do you need this to interoperate > with with other TLS clients or servers? > > For closed environments, there are simpler secure communications > options than TLS, DJBs crypto box comes to mind: > > http://nacl.cr.yp.to/features.html > http://nacl.cr.yp.to/box.html > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > -- > Regards, > Ajay > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
