How to make a secure tcp connection without using certificate

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

How to make a secure tcp connection without using certificate

Subrata Dasgupta
Hello Sir / Madam,

I am very much new to openssl programming. I want to make a TCP connection secure using openssl. I do not want to use any certificate or keys.. Is it possible to make a TCP connection secure without using certificate or keys?? I am using openssl-0.9.7a.

To make a TCP connection secure I have changed two example files of the openssl-0.9.7a source code under demo/ssl. I am attaching those changed files with this email. I changed those files to avoid certificate and keys related openssl calls.. But server and client both are giving following errors.. Please please help..

In Server ...
Connection from 100007f, port 8fc0
SSL connection using (NONE)
7778:error:140EC0E5:SSL routines:SSL2_READ_INTERNAL:ssl handshake failure:s2_pkt.c:143:


In Client ...
7779:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:138:
7779:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header:tasn_dec.c:928:
7779:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:304:Type=X509
7779:error:1407E00B:SSL routines:SSL2_SET_CERTIFICATE:X509 lib:s2_clnt.c:1050:


Below are the openssl library calls made by the server..
SSL_library_init();
SSL_load_error_strings();
SSLeay_add_ssl_algorithms();
meth = SSLv23_server_method();
ctx = SSL_CTX_new (meth);
ssl = SSL_new (ctx);
SSL_set_fd (ssl, sd);
err = SSL_accept (ssl);
SSL_read (ssl, buf, sizeof(buf) - 1);
err = SSL_write (ssl, "I hear you.", strlen("I hear you."));
SSL_free (ssl);
SSL_CTX_free (ctx);


In client following calls are made...
SSL_library_init();
SSLeay_add_ssl_algorithms();
meth = SSLv2_client_method();
SSL_load_error_strings();
ctx = SSL_CTX_new (meth);
ssl = SSL_new (ctx);
SSL_set_fd (ssl, sd);
err = SSL_connect (ssl);
err = SSL_write (ssl, "Hello World!", strlen("Hello World!")); CHK_SSL(err);
err = SSL_read (ssl, buf, sizeof(buf) - 1);
SSL_shutdown (ssl);
SSL_free (ssl);
SSL_CTX_free (ctx);


Thanks
Subrata

Get your own FREE website, FREE domain & FREE mobile app with Company email.  
Know More >
Reply | Threaded
Open this post in threaded view
|

Re: How to make a secure tcp connection without using certificate

Bernhard Fröhlich-2
Am 23.05.2014 14:16, schrieb Subrata Dasgupta:
Hello Sir / Madam,

I am very much new to openssl programming. I want to make a TCP connection secure using openssl. I do not want to use any certificate or keys.. Is it possible to make a TCP connection secure without using certificate or keys?? I am using openssl-0.9.7a.

To make a TCP connection secure I have changed two example files of the openssl-0.9.7a source code under demo/ssl. I am attaching those changed files with this email. I changed those files to avoid certificate and keys related openssl calls.. But server and client both are giving following errors.. Please please help..

Hello Subrata,

if you don't use a certificate at least for your server you won't get a secure connection. At least not with OpenSSL.

You'll have to create a certificate and keys, but you can create a self signed certificate (https://www.google.de/search?q=create+self+signed+certificate) or use some free certificate provider, like for example http://www.cacert.org

The server has to use the private keys (check SSL_CTX_use_PrivateKey*) and offer the certificate to the client (SSL_CTX_use_certificate*), then you may at least get your test setup running.

Of course, a certificate alone will not guarantee a "secure" connection, but explaining how to get a connection secured for production use is above my available time... :-\

Hope it helps
Ted
;)

In Server ...
Connection from 100007f, port 8fc0
SSL connection using (NONE)
7778:error:140EC0E5:SSL routines:SSL2_READ_INTERNAL:ssl handshake failure:s2_pkt.c:143:


In Client ...
7779:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:138:
7779:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header:tasn_dec.c:928:
7779:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:304:Type=X509
7779:error:1407E00B:SSL routines:SSL2_SET_CERTIFICATE:X509 lib:s2_clnt.c:1050:


Below are the openssl library calls made by the server..
SSL_library_init();
SSL_load_error_strings();
SSLeay_add_ssl_algorithms();
meth = SSLv23_server_method();
ctx = SSL_CTX_new (meth);
ssl = SSL_new (ctx);
SSL_set_fd (ssl, sd);
err = SSL_accept (ssl);
SSL_read (ssl, buf, sizeof(buf) - 1);
err = SSL_write (ssl, "I hear you.", strlen("I hear you."));
SSL_free (ssl);
SSL_CTX_free (ctx);


In client following calls are made...
SSL_library_init();
SSLeay_add_ssl_algorithms();
meth = SSLv2_client_method();
SSL_load_error_strings();
ctx = SSL_CTX_new (meth);
ssl = SSL_new (ctx);
SSL_set_fd (ssl, sd);
err = SSL_connect (ssl);
err = SSL_write (ssl, "Hello World!", strlen("Hello World!")); CHK_SSL(err);
err = SSL_read (ssl, buf, sizeof(buf) - 1);
SSL_shutdown (ssl);
SSL_free (ssl);
SSL_CTX_free (ctx);


Thanks
Subrata

Get your own FREE website, FREE domain & FREE mobile app with Company email.  
Know More >


-- 
PGP Public Key Information
Download complete Key from http://www.convey.de/ted/tedkey_convey.asc
Key fingerprint = 31B0 E029 BCF9 6605 DAC1  B2E1 0CC8 70F4 7AFB 8D26
Reply | Threaded
Open this post in threaded view
|

RE: How to make a secure tcp connection without using certificate

Michael Wojcik
In reply to this post by Subrata Dasgupta

There's no such thing as a "secure" TCP conversation, or any other communication channel, except in the context of a threat model - and even then security only applies in relative terms, to things like risk probabililties and costs. Security is not an absolute condition.

 

Thus there's no way to answer your question, because we don't know what "secure" means for your application.

 

SSL/TLS are designed to provide cryptographic security features for TCP (and now, with DTLS, UDP) communications channels. That's often described in terms of four basic feature areas: confidentiality, message integrity, authentication, and non-repudiation. What does your application require in each of those areas? What's your threat model? What classes of attacks are you looking to defend against, and what work factor for an adversary is considered an acceptable defense?

 

It's possible that the answer to your technical question is "use cipher suites that support anonymous key exchange". This is quite likely the Wrong Thing for most real-world applications that have some perceived need for communications security.

 

Michael Wojcik
Technology Specialist, Micro Focus

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Subrata Dasgupta
Sent: Friday, 23 May, 2014 08:17
To: [hidden email]
Subject: How to make a secure tcp connection without using certificate

 

Hello Sir / Madam,

I am very much new to openssl programming. I want to make a TCP connection secure using openssl. I do not want to use any certificate or keys.. Is it possible to make a TCP connection secure without using certificate or keys?? I am using openssl-0.9.7a.

To make a TCP connection secure I have changed two example files of the openssl-0.9.7a source code under demo/ssl. I am attaching those changed files with this email. I changed those files to avoid certificate and keys related openssl calls.. But server and client both are giving following errors.. Please please help..

In Server ...
Connection from 100007f, port 8fc0
SSL connection using (NONE)
7778:error:140EC0E5:SSL routines:SSL2_READ_INTERNAL:ssl handshake failure:s2_pkt.c:143:


In Client ...
7779:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:138:
7779:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header:tasn_dec.c:928:
7779:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:304:Type=X509
7779:error:1407E00B:SSL routines:SSL2_SET_CERTIFICATE:X509 lib:s2_clnt.c:1050:


Below are the openssl library calls made by the server..
SSL_library_init();
SSL_load_error_strings();
SSLeay_add_ssl_algorithms();
meth = SSLv23_server_method();
ctx = SSL_CTX_new (meth);
ssl = SSL_new (ctx);
SSL_set_fd (ssl, sd);
err = SSL_accept (ssl);
SSL_read (ssl, buf, sizeof(buf) - 1);
err = SSL_write (ssl, "I hear you.", strlen("I hear you."));
SSL_free (ssl);
SSL_CTX_free (ctx);


In client following calls are made...
SSL_library_init();
SSLeay_add_ssl_algorithms();
meth = SSLv2_client_method();
SSL_load_error_strings();
ctx = SSL_CTX_new (meth);
ssl = SSL_new (ctx);
SSL_set_fd (ssl, sd);
err = SSL_connect (ssl);
err = SSL_write (ssl, "Hello World!", strlen("Hello World!")); CHK_SSL(err);
err = SSL_read (ssl, buf, sizeof(buf) - 1);
SSL_shutdown (ssl);
SSL_free (ssl);
SSL_CTX_free (ctx);


Thanks
Subrata

 

Know More >

 

Click here to report this email as spam.



This message has been scanned for malware by Websense. www.websense.com

Reply | Threaded
Open this post in threaded view
|

Re : How to make a secure tcp connection without using certificate

nicolas.kox
In reply to this post by Subrata Dasgupta
Hi,

not really answering the initial question, but these could be some good advices :

first of all, upgrade your library to the latest version (1.0.1g I think), the one you're using seems a bit old and download is free ;-p


second, you should avoid SSLv2, it is not secure anymore, and since a bunch of time
use at the very least TLSv1 (and preferably TLSv1_2) protocol
if you want to use SSLv23_server_method(), don't forget to disable SSLv2 and 3 protocols (and maybe TLSv1) with the command

SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3);


third, you should also be cautious with which symetric cipher you use : by default, you still have RC2 and DES activated until TLSv1.1, RC4 and 3DES in TLSv1.2, which are either unsecure or will soon be
you could use these lines to avoid unsecure ciphers :

#define CIPHERS "HIGH:+MEDIUM:!aNULL:!eNULL:!3DES:!RC4:!RC2!DES"
SSL_CTX_set_cipher_list(ctx, CIPHERS);

Best is to use AES with GCM mode if you're really aiming for security

There are many other mistakes you can do, but with this, you should avoid the worst.


And about your initial question, the answer is definitely not.

The fact is you can't garantee at all that no one is spying on your packets on the network, not even that you are talking to the good computer...
To prevent the first you need to encrypt your data (and thus use a key at some point), and to prevent the second you need a certificate (which basically contains a public key)


Nico

PS : in fact it can be secure, only if there's absolutely nothing but a cable between the two computers. But not even totally since it is still possible to spy on electromagnetic noise (I'm not even joking)


----- Mail d'origine -----
De: Subrata Dasgupta <[hidden email]>
À: [hidden email]
Envoyé: Fri, 23 May 2014 14:16:33 +0200 (CEST)
Objet: How to make a secure tcp connection without using certificate

Hello Sir / Madam,

I am very much new to openssl programming. I want to make a TCP connection secure using openssl. I do not want to use any certificate or keys.. Is it possible to make a TCP connection secure without using certificate or keys?? I am using openssl-0.9.7a.

To make a TCP connection secure I have changed two example files of the openssl-0.9.7a source code under demo/ssl. I am attaching those changed files with this email. I changed those files to avoid certificate and keys related openssl calls.. But server and client both are giving following errors.. Please please help..

In Server ...
Connection from 100007f, port 8fc0
SSL connection using (NONE)
7778:error:140EC0E5:SSL routines:SSL2_READ_INTERNAL:ssl handshake failure:s2_pkt.c:143:


In Client ...
7779:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:138:
7779:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header:tasn_dec.c:928:
7779:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:304:Type=X509
7779:error:1407E00B:SSL routines:SSL2_SET_CERTIFICATE:X509 lib:s2_clnt.c:1050:


Below are the openssl library calls made by the server..
  SSL_library_init();
  SSL_load_error_strings();
  SSLeay_add_ssl_algorithms();
  meth = SSLv23_server_method();
  ctx = SSL_CTX_new (meth);
  ssl = SSL_new (ctx);
  SSL_set_fd (ssl, sd);
  err = SSL_accept (ssl);        
  SSL_read (ssl, buf, sizeof(buf) - 1);
  err = SSL_write (ssl, "I hear you.", strlen("I hear you."));
  SSL_free (ssl);
  SSL_CTX_free (ctx);


In client following calls are made...
  SSL_library_init();
  SSLeay_add_ssl_algorithms();
  meth = SSLv2_client_method();
  SSL_load_error_strings();
  ctx = SSL_CTX_new (meth);  
  ssl = SSL_new (ctx);
  SSL_set_fd (ssl, sd);
  err = SSL_connect (ssl);  
  err = SSL_write (ssl, "Hello World!", strlen("Hello World!"));  CHK_SSL(err);
  err = SSL_read (ssl, buf, sizeof(buf) - 1);
  SSL_shutdown (ssl);
  SSL_free (ssl);
  SSL_CTX_free (ctx);


Thanks
Subrata

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re?: How to make a secure tcp connection without using certificate

Viktor Dukhovni
On Fri, May 23, 2014 at 06:11:05PM +0200, [hidden email] wrote:

> use at the very least TLSv1 (and preferably TLSv1_2) protocol if you want
> to use SSLv23_server_method(), don't forget to disable SSLv2 and 3 protocols
> (and maybe TLSv1) with the command
>
> SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3);

Typically, leaving SSLv3 enabled is just fine if both ends support
something stronger they'll negotiate that.

> third, you should also be cautious with which symetric cipher you use :
> by default, you still have RC2 and DES activated until TLSv1.1, RC4 and
> 3DES in TLSv1.2, which are either unsecure or will soon be you could use
> these lines to avoid unsecure ciphers :

Again, with the DEFAULT cipherlist, one generally negotiates the
strongest mutually-available cipher-suite, and there is little need
to disable weaker ciphers.  However, since nobody uses export cipher
suites or single DES anymore, the simplest cipher-suite tweak is:

        DEFAULT:!EXPORT:!LOW

if certificates are required or

        ALL:!EXPORT:!LOW

if anonymous (ADH or AECDH) cipher-suites are needed.

> #define CIPHERS "HIGH:+MEDIUM:!aNULL:!eNULL:!3DES:!RC4:!RC2!DES"
> SSL_CTX_set_cipher_list(ctx, CIPHERS);

This is broken, HIGH includes no MEDIUM ciphers, so the "+MEDIUM" has
no effect.  The OP seemed to want no certificates, so "!aNULL" is
perhaps too restrictive.  There's a missing ":" between "!RC2" and
not "!DES", but there are no DES or RC2 ciphers in HIGH, so it is not
clear why these are present.

As for the OP's question, it was very poorly stated, and it is far
from clear what a sensible answer might be.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re : Re: Re?: How to make a secure tcp connection without using certificate

nicolas.kox
thanks for the precisions

leaving SSLv3 active is ok if he is the only one to connect, as well as for ciphers
but a rogue client can still force downgrade for both cipher and protocol...


for the cipher list I did clearly not choose the more efficient way to do this
however I think it is still preferable to remove some ciphers twice than not at all


concerning anonymous authentication, I'm still not convinced that it could be considered safe when establishing a "secure" connection
still, the only way to be sure is to exchange certificates (or maybe a symmetric key) offline prior any communication

Nico

----- Mail d'origine -----
De: Viktor Dukhovni <[hidden email]>
À: [hidden email]
Envoyé: Fri, 23 May 2014 18:32:15 +0200 (CEST)
Objet: Re: Re?: How to make a secure tcp connection without using certificate

On Fri, May 23, 2014 at 06:11:05PM +0200, [hidden email] wrote:

> use at the very least TLSv1 (and preferably TLSv1_2) protocol if you want
> to use SSLv23_server_method(), don't forget to disable SSLv2 and 3 protocols
> (and maybe TLSv1) with the command
>
> SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3);

Typically, leaving SSLv3 enabled is just fine if both ends support
something stronger they'll negotiate that.


> third, you should also be cautious with which symetric cipher you use :
> by default, you still have RC2 and DES activated until TLSv1.1, RC4 and
> 3DES in TLSv1.2, which are either unsecure or will soon be you could use
> these lines to avoid unsecure ciphers :

Again, with the DEFAULT cipherlist, one generally negotiates the
strongest mutually-available cipher-suite, and there is little need
to disable weaker ciphers.  However, since nobody uses export cipher
suites or single DES anymore, the simplest cipher-suite tweak is:

        DEFAULT:!EXPORT:!LOW

if certificates are required or

        ALL:!EXPORT:!LOW

if anonymous (ADH or AECDH) cipher-suites are needed.

> #define CIPHERS "HIGH:+MEDIUM:!aNULL:!eNULL:!3DES:!RC4:!RC2!DES"
> SSL_CTX_set_cipher_list(ctx, CIPHERS);

This is broken, HIGH includes no MEDIUM ciphers, so the "+MEDIUM" has
no effect.  The OP seemed to want no certificates, so "!aNULL" is
perhaps too restrictive.  There's a missing ":" between "!RC2" and
not "!DES", but there are no DES or RC2 ciphers in HIGH, so it is not
clear why these are present.

As for the OP's question, it was very poorly stated, and it is far
from clear what a sensible answer might be.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re?: How to make a secure tcp connection without using certificate

Hanno Böck-4
In reply to this post by Viktor Dukhovni
On Fri, 23 May 2014 16:32:15 +0000
Viktor Dukhovni <[hidden email]> wrote:

> On Fri, May 23, 2014 at 06:11:05PM +0200, [hidden email] wrote:
>
> > use at the very least TLSv1 (and preferably TLSv1_2) protocol if
> > you want to use SSLv23_server_method(), don't forget to disable
> > SSLv2 and 3 protocols (and maybe TLSv1) with the command
> >
> > SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3);
>
> Typically, leaving SSLv3 enabled is just fine if both ends support
> something stronger they'll negotiate that.
That's not always true.

Some clients (e.g. all common browsers) do fallbacks that in fact
can invalidate all improvements of later tls versions.

These fallbacks also can happen by accident (e.g. bad connections) and
sometimes disable features like SNI.

That's why I recommend to everyone that we need at least to deprecate
SSLv3.

--
Hanno Böck
http://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re?: How to make a secure tcp connection without using certificate

Viktor Dukhovni
On Sun, May 25, 2014 at 02:22:34PM +0200, Hanno B?ck wrote:

> > Typically, leaving SSLv3 enabled is just fine if both ends support
> > something stronger they'll negotiate that.
>
> That's not always true.

In a browser fallback (only relevant here if the OP is implementing
an HTTP server) nothing stronger is advertised by the client.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re?: How to make a secure tcp connection without using certificate

Jakob Bohm-7
In reply to this post by Hanno Böck-4
On 5/25/2014 2:22 PM, Hanno Böck wrote:

> On Fri, 23 May 2014 16:32:15 +0000
> Viktor Dukhovni <[hidden email]> wrote:
>
>> On Fri, May 23, 2014 at 06:11:05PM +0200, [hidden email] wrote:
>>
>>> use at the very least TLSv1 (and preferably TLSv1_2) protocol if
>>> you want to use SSLv23_server_method(), don't forget to disable
>>> SSLv2 and 3 protocols (and maybe TLSv1) with the command
>>>
>>> SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3);
>>
>> Typically, leaving SSLv3 enabled is just fine if both ends support
>> something stronger they'll negotiate that.
>
> That's not always true.
>
> Some clients (e.g. all common browsers) do fallbacks that in fact
> can invalidate all improvements of later tls versions.
>
> These fallbacks also can happen by accident (e.g. bad connections) and
> sometimes disable features like SNI.
>
> That's why I recommend to everyone that we need at least to deprecate
> SSLv3.
>


There is also the very real issue that a few platforms which no longer
receive feature updates (such as new TLS protocol versions) are stuck
at SSLv3.  Permanently.  So until those platforms become truly extinct,
a lot of servers need to cater to their continued existence by allowing
ancient TLS versions.

At that point the problem is how to do the best defense against
man-in-the-middle downgrade-to-SSLv3 attacks.  For instance is there a
way to
ensure that the server certificate validation done by an SSLv3
(compatible) client will fail if both server and client were capable of
TLS v1.0, but a man in the middle tampered with the version negotiation?

Failing that, is this something that could be added to the TLS v1.3
standard (i.e. some signed portion of the SSLv3 exchange being
unnaturally different if the parties could and should have negotiated
something better).

Not remembering the SSLv3 spec details, one option could be to announce
support for a special "we also support TLS v1.0" cipher suite, which no
one can really implement (by definition), but whose presence in a
cipher suite list from the other end indicates that said other end
announced SSLv3.1 (TLS v1.0) support in an unsigned part of the
exchange.  This could even be specified in an "UPDATE RFC" for the
existing TLS v1.0..v1.2 versions, and a CVE number assigned to the
common bug of its non-implementation (after library implementations
become available).



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, 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 Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Re?: How to make a secure tcp connection without using certificate

Dave Thompson-5
> From: [hidden email] On Behalf Of Jakob Bohm
> Sent: Wednesday, May 28, 2014 13:04

> On 5/25/2014 2:22 PM, Hanno Böck wrote:

> > Some clients (e.g. all common browsers) do fallbacks that in fact
> > can invalidate all improvements of later tls versions.
> >
> > These fallbacks also can happen by accident (e.g. bad connections) and
> > sometimes disable features like SNI.
> >
> > That's why I recommend to everyone that we need at least to deprecate
> > SSLv3.
> >
>
>
> There is also the very real issue that a few platforms which no longer
> receive feature updates (such as new TLS protocol versions) are stuck
> at SSLv3.  Permanently.  So until those platforms become truly extinct,
> a lot of servers need to cater to their continued existence by allowing
> ancient TLS versions.
>
> At that point the problem is how to do the best defense against
> man-in-the-middle downgrade-to-SSLv3 attacks.  For instance is there a
> way to
> ensure that the server certificate validation done by an SSLv3
> (compatible) client will fail if both server and client were capable of
> TLS v1.0, but a man in the middle tampered with the version negotiation?
>
I don't think you want it on the cert. The cert only asserts identity and
ownership of the key, it isn't specific to the server implementation or
features and making it so would I bet actually discourage people from
upgrading to the latest and most complete protocol (not a benefit).
And of course very few TLS connections use a client cert, so the
server would almost never be able to detect/report the problem,
even though a decent server operator would like to know about an attack
targeted (substantially) at them and their users, and I'd bet is more likely
to try to do something about it than most web users at least.

The Finished exchange protects against *tampering* in a handshake,
and has since SSLv3 (inclusive). The problem is clients that fall back
at the application level if the (good) handshake is *blocked* (denied).
Remember we had a fair number of "legit" cases of this when TLSv1.2
in 1.0.1 added numerous suites by default plus one extension and
ClientHello growing beyond 256 broke some servers -- even though
they claimed to implement specs that implicitly required it. In those cases
it was actually reasonable for a client to fall back to 1.1.

> Failing that, is this something that could be added to the TLS v1.3
> standard (i.e. some signed portion of the SSLv3 exchange being
> unnaturally different if the parties could and should have negotiated
> something better).
>
I see no reason to tie this to a TLSv1.3 document, when and if there is one.
This is a proposed change to SSL, which is not TLS (only technically similar).
The "prohibition" on SSLv2 is a standalone document: 6176, which updates
2246 4346 5246 to retroactively remove the SSLv2 compatibility.
(Of course an IETF prohibition has no legal force and doesn't actually
prevent or even deter people from continuing to use SSLv2, it just lets us
wag our fingers at them.) Since SSLv3 was belatedly retroactively published
as 6101, this could even be labelled as an update to that, FWIW.

> Not remembering the SSLv3 spec details, one option could be to announce
> support for a special "we also support TLS v1.0" cipher suite, which no
> one can really implement (by definition), but whose presence in a
> cipher suite list from the other end indicates that said other end
> announced SSLv3.1 (TLS v1.0) support in an unsigned part of the
> exchange.  This could even be specified in an "UPDATE RFC" for the
> existing TLS v1.0..v1.2 versions, and a CVE number assigned to the
> common bug of its non-implementation (after library implementations
> become available).
>
In other words like the Signaling CipherSuite Value (SCSV) used for
5746 Secure Renegotiation (aka the Apache bug) in cases where the
extension didn't work (or might not work reliably). I'd say experience
confirmed that worked well enough to be considered an option.

But many users, especially web users, want to connect to the server
even if it isn't "truly" secure. When we make it harder for https to
work, they *will* use http instead, or else complain very loudly.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re?: How to make a secure tcp connection without using certificate

Jakob Bohm-7
On 5/30/2014 12:03 AM, Dave Thompson wrote:

>> From: [hidden email] On Behalf Of Jakob Bohm
>> Sent: Wednesday, May 28, 2014 13:04
>
>> On 5/25/2014 2:22 PM, Hanno Böck wrote:
>
>>> Some clients (e.g. all common browsers) do fallbacks that in fact
>>> can invalidate all improvements of later tls versions.
>>>
>>> These fallbacks also can happen by accident (e.g. bad connections) and
>>> sometimes disable features like SNI.
>>>
>>> That's why I recommend to everyone that we need at least to deprecate
>>> SSLv3.
>>>
>>
>>
>> There is also the very real issue that a few platforms which no longer
>> receive feature updates (such as new TLS protocol versions) are stuck
>> at SSLv3.  Permanently.  So until those platforms become truly extinct,
>> a lot of servers need to cater to their continued existence by allowing
>> ancient TLS versions.
>>
>> At that point the problem is how to do the best defense against
>> man-in-the-middle downgrade-to-SSLv3 attacks.  For instance is there a
>> way to
>> ensure that the server certificate validation done by an SSLv3
>> (compatible) client will fail if both server and client were capable of
>> TLS v1.0, but a man in the middle tampered with the version negotiation?
>>
> I don't think you want it on the cert.

Sorry for the sloppy wording, I obviously meant the certificate powered
validation of the handshake, not the certificate attributes.

>
> The Finished exchange protects against *tampering* in a handshake,
> and has since SSLv3 (inclusive). The problem is clients that fall back
> at the application level if the (good) handshake is *blocked* (denied).
> Remember we had a fair number of "legit" cases of this when TLSv1.2
> in 1.0.1 added numerous suites by default plus one extension and
> ClientHello growing beyond 256 broke some servers -- even though
> they claimed to implement specs that implicitly required it. In those cases
> it was actually reasonable for a client to fall back to 1.1.
>
>> Failing that, is this something that could be added to the TLS v1.3
>> standard (i.e. some signed portion of the SSLv3 exchange being
>> unnaturally different if the parties could and should have negotiated
>> something better).
>>
> I see no reason to tie this to a TLSv1.3 document, when and if there is one.
> This is a proposed change to SSL, which is not TLS (only technically similar).
> The "prohibition" on SSLv2 is a standalone document: 6176, which updates
> 2246 4346 5246 to retroactively remove the SSLv2 compatibility.
> (Of course an IETF prohibition has no legal force and doesn't actually
> prevent or even deter people from continuing to use SSLv2, it just lets us
> wag our fingers at them.) Since SSLv3 was belatedly retroactively published
> as 6101, this could even be labelled as an update to that, FWIW.
>
>> Not remembering the SSLv3 spec details, one option could be to announce
>> support for a special "we also support TLS v1.0" cipher suite, which no
>> one can really implement (by definition), but whose presence in a
>> cipher suite list from the other end indicates that said other end
>> announced SSLv3.1 (TLS v1.0) support in an unsigned part of the
>> exchange.  This could even be specified in an "UPDATE RFC" for the
>> existing TLS v1.0..v1.2 versions, and a CVE number assigned to the
>> common bug of its non-implementation (after library implementations
>> become available).
>>
> In other words like the Signaling CipherSuite Value (SCSV) used for
> 5746 Secure Renegotiation (aka the Apache bug) in cases where the
> extension didn't work (or might not work reliably). I'd say experience
> confirmed that worked well enough to be considered an option.
>
> But many users, especially web users, want to connect to the server
> even if it isn't "truly" secure. When we make it harder for https to
> work, they *will* use http instead, or else complain very loudly.
>

Indeed, that is why such TLSvX.Y SCSVs need to be carefully designed to
specify what each one claims other than simply "every (obscure or not)
aspect of some very long spec, which might have common  misimplementations".



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, 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 Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]