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-us...@dukhovni.org <mailto:openssl-us...@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

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Reply via email to