[openssl-users] SSL Signalling
Jakob Bohm
jb-openssl at wisemo.com
Mon Aug 17 06:29:08 UTC 2015
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
More information about the openssl-users
mailing list