Re: [openssl-users] session resumption tls1.2/tls1.3

[Neetish Pathak]

Thanks Ben for your reply

On Tue, Jul 25, 2017 at 6:11 AM, Benjamin Kaduk  wrote:

> [Matt's reply is likely to be high latency]
>
>
> On 07/24/2017 08:53 PM, Neetish Pathak wrote:
>
>
>
> On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell  wrote:
>
>>
>>
>> On 18/07/17 22:27, Neetish Pathak wrote:
>> > Hi ,
>> > thanks Matt, this is helpful
>> >
>> >
>> > One more query on how I can enable 0.5 RTT data from the server side. It
>> > is mentioned in TLS 1.3 specification. I thought it can be implemented
>> > by sending early data  from server side after reading the early data.
>>
>> That is correct, and is as documented on this page:
>>
>> https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html
>> 
>
>
>
> Thanks Matt
> To send 0.5 RTT data I m sending the early_data from the server side just
> after the early_read data. But when I see the wire-shark logs, I see that
> the server data is sent only once the complete handshake has taken place.
> (which is the same as using SSL_write after SSL_accept).
> I am performing following steps on client and server respectively as per
> understanding developed from previous discussions
>
> *Pseudocode for client*
>
> tcp_connect
>
> write_early(data)
>
> ssl_connect
>
> if(early_data_write_failed){
>   ssl_write(data)
> }
>
> ssl_read
>
>
> *Pseudocode for server*
>
> tcp_accept
>
> read_early{
>
>  if(read_early_success){
>   write_early(data)
>   }
> }
>
> ssl_accept
>
> if(read_early_fail){
> ssl_read
> ssl_write(data)
> }
>
>
> I am measuring latency on the *client side* from TCP connection start
>  till it completes the read (ssl_read returns) (analogues to making a
> request from client and reading response).
> Please suggest what may be going wrong basically with these queries
>
> 1) Why is there no difference (or negligible) in latencies when i use
> early write and then later ssl_read compared to when I execute normal
> write/read on the client side
>
>
> Maybe I misunderstand the question, but isn't this is just a natural
> consequence of the server (mis)behavior in (2)?
>


Yes, this is right, the server misbehavior is causing this.


>
>
> 2) Why does the server not send data (for early write) after the server
> Hello(and other encrypted message) message even when early_write succeeds
> on server side. Why does server wait to finish the handshake. I know it
> waits because I see client sending encrypted messages after server hello
> message before my intended application data gets sent from server. These
> encrypted messages from the client side are the usual messages from the
> client side for handshake completion.
>
>
> From a quick look through the state machine code, this is supposed to
> work.  But someone would probably have to instrument the code (e.g., with
> printf) to tell why the delay is being introduced.  I don't think I have
> the availability to do so in the near future, myself.
>


I see that the application data is not being sent from server to an
unauthenticated client. The server is sending data only after receiving
some encrypted message which I believe is the EndOfEarlyData and Finished
messages. Following is  a dump of wireshark logs for the communication with
early data enabled. I also tried with some logs in Openssl libraries, I see
early data gets written from server side when write_early_data is called.
Internally SSL_write_ex is called which completes write and handshake. But
I am not sure why application data is not actually pushed from the server
side. It is waiting for the Client finished message.
I have disabled Nagle's algo during this operation.

Client port is 56806 and server port is 12345


No. Time   SourceDestination   Protocol
Length Info
207 18.380298  ::1   ::1   TLSv1.3
 956Client Hello   - Client Hello


No. Time   SourceDestination   Protocol
Length Info
208 18.380335  ::1   ::1   TLSv1.3
 2849   Application Data   --*Early Data from the
client side (Intended Application Data)*
Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq: 881,
Ack: 1, Len: 2773

No. Time   SourceDestination   Protocol
Length Info
211 18.380624  ::1   ::1   TLSv1.3
 219Server Hello, Application Data, Application Data . Server
Hello and (encrypted handshake message/extensions)
Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 1,
Ack: 3654, Len: 143

No. 

Re: [openssl-users] Considering C# OpenSSL openssl-net-master

[Salz, Rich via openssl-users]

If you want to use those ciphers, you need to set SECLEVEL=0 when you specify 
the ciphers.
I have no idea how to do that for the OpoenSSL C# binding.  Maybe post an issue 
on openssl-net?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Considering C# OpenSSL openssl-net-master

[Hegazi, Amr]

Hello *,

I'm using the last version of C# OpenSSL from 
https://github.com/openssl-net/openssl-net (This wrapper is based on version 
1.0.2a of libeay32.dll and ssleay32.dll).

I'm using C# OpenSSL to test my Tls Client that supports TLS starting from 
version 1.2 and all the cipher suites. Moreover, I'm using Microsoft windows 7. 
I have already installed Microsoft visual C++ 2010 express and Microsoft visual 
Studio 2010.

I always face an error "TLSv1.2  81 - Alert (Level: Fatal, Description: 
Insufficient Security)"

I have debugged the issue. The issue come from a function called SSL_CTX_new() 
which is connected to ssleay32.dll. the clienthello is always sent correctly 
and then the OpenSSL server replies with Insufficient Security

The console also shows this:
.NET   HSM Received: ClientHello (188 bytes)
.NET   Offered suite by client: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 
(0xc02b) [not supported]
.NET   Offered suite by client: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 
(0xc023) [not supported]
.NET   Offered suite by client: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) 
[not supported]
.NET   Offered suite by client: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) 
[not supported]
.NET   Offered suite by client: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) 
[not supported]
.NET   Offered suite by client: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) [not 
supported]
.NET   Offered suite by client: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) [not 
supported]
.NET   Offered suite by client: TLS_ECDH_ECDSA_WITH_NULL_SHA (0xc001) [not 
supported]
.NET   Offered suite by client: TLS_RSA_WITH_NULL_SHA256 (0x003b) [not 
supported]
.NET   Offered suite by client: TLS_RSA_WITH_NULL_SHA (0x0002) [not supported]
.NET   ALERT SENT: Fatal InsufficientSecurity
.NET   no shared cipher suites

And in Wireshark shows this:

"3406.315537","fe80::ff:fe00:2","fe80::1:5","SSL","271","Client Hello"
"3419.805155","fe80::1:5","fe80::ff:fe00:2","TLSv1.2","81","Alert (Level: 
Fatal, Description: Insufficient Security)"

So, I think the error is in something related to configuration of ssleay32.dll

My code is simple and is as follows:

try
{
  TestCaseBegin();

Output.WriteLine("TLS Server Certificate preparation");
CertDir = Path.GetFullPath("..\\Appl\\Certificates\\Certificate");
TlsServerCertificate = loadCertificateFromFile(Path.Combine(CertDir, 
@"Vector_ServerCertificate_RsaSha1_IA_pfx.pfx"), "123456");
TlsServerCaCertificates = new 
X509Chain(OpenSSL.Core.BIO.File(Path.Combine(CertDir, 
@"Vector_ServerCertificate_RsaSha1_Root_cert.cer"), "r"));

Output.WriteLine("Start connection");
TS_RcTlsConnect(TlsConnectMode.Rsa);

Output.WriteLine("Send Client Hello");
TS_WaitForTcpConnection();

Output.WriteLine("make sslStreamServer");
SslStream sslStreamServer = new SslStream(tcpClient.GetStream(), true, 
MyRemoteCertificateValidationHandler,MyLocalCertificateSelectionHandler);

Output.WriteLine("Start AuthenticateAsServer");

sslStreamServer.AuthenticateAsServer(TlsServerCertificate, false, 
TlsServerCaCertificates, SslProtocols.Tls, SslStrength.All, false);
}

catch (TestStepFailException e)
{
HandleTestStepFailException(e);
Output.WriteLine(e.ToString());
 }
   catch (Exception ex)
{
PrintException(ex);
Output.WriteLine(ex.ToString());
 }
finally
{
TestCaseEnd();
}

Has anyone an idea?

Best Regards;

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

Re: [openssl-users] Open ssl & Freeradius

[Thomas J. Hruska]

On 7/25/2017 4:15 AM, Seniha S. ÖZTEMİZ TULGAR wrote:

Hello,

I installed the new version of freeradius and trying to configure it. My
windows10 clients gets authenticated but windows7 clients gets the
following errors. It seems that it is about openssl. Can you help me
regarding this problem. Any suggestions ?


You are technically on the wrong list.  The Freeradius project has its 
own user mailing list.  You should ask questions about Freeradius on 
that list.




Tue Jul 25 14:11:59 2017 : Error: tls: TLS_accept: Error in error


This line is entertaining.  (But not relevant.)



Tue Jul 25 14:11:59 2017 : ERROR: (1) eap_ttls: Failed in __FUNCTION__
(SSL_read): ../ssl/statem/statem_srvr.c[1404]:error:1417A0C1:SSL
routines:tls_post_process_client_hello:no shared cipher


This is your problem.  The handshake between Freeradius and your client 
failed due to "no shared cipher".  Change your server and/or client 
cipher list(s) to something compatible.


--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] session resumption tls1.2/tls1.3

[Benjamin Kaduk via openssl-users]

[Matt's reply is likely to be high latency]

On 07/24/2017 08:53 PM, Neetish Pathak wrote:
>
>
> On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell  > wrote:
>
>
>
> On 18/07/17 22:27, Neetish Pathak wrote:
> > Hi ,
> > thanks Matt, this is helpful
> >
> >
> > One more query on how I can enable 0.5 RTT data from the server
> side. It
> > is mentioned in TLS 1.3 specification. I thought it can be
> implemented
> > by sending early data  from server side after reading the early
> data.
>
> That is correct, and is as documented on this page:
>
> https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html
> 
> 
>
>
>
> Thanks Matt
> To send 0.5 RTT data I m sending the early_data from the server side
> just after the early_read data. But when I see the wire-shark logs, I
> see that the server data is sent only once the complete handshake has
> taken place. (which is the same as using SSL_write after SSL_accept).
> I am performing following steps on client and server respectively as
> per understanding developed from previous discussions
>
> *Pseudocode for client*
> *
> *
> tcp_connect
>
> write_early(data)
>
> ssl_connect
>
> if(early_data_write_failed){
>   ssl_write(data)
> }
>
> ssl_read
>
>
> *Pseudocode for server*
> *
> *
> tcp_accept
> *
> *
> read_early{
>
>  if(read_early_success){
>   write_early(data)
>   }
> }
>
> ssl_accept
>
> if(read_early_fail){
> ssl_read
> ssl_write(data)
> }
>
>
> I am measuring latency on the *client side* from TCP connection start
>  till it completes the read (ssl_read returns) (analogues to making a
> request from client and reading response).
> Please suggest what may be going wrong basically with these queries
>
> 1) Why is there no difference (or negligible) in latencies when i use
> early write and then later ssl_read compared to when I execute normal
> write/read on the client side
>

Maybe I misunderstand the question, but isn't this is just a natural
consequence of the server (mis)behavior in (2)?

> 2) Why does the server not send data (for early write) after the
> server Hello(and other encrypted message) message even when
> early_write succeeds on server side. Why does server wait to finish
> the handshake. I know it waits because I see client sending encrypted
> messages after server hello message before my intended application
> data gets sent from server. These encrypted messages from the client
> side are the usual messages from the client side for handshake completion.
>

>From a quick look through the state machine code, this is supposed to
work.  But someone would probably have to instrument the code (e.g.,
with printf) to tell why the delay is being introduced.  I don't think I
have the availability to do so in the near future, myself.

> 3) Also, the performance of TLS 1.3 using early data or resumption is
> worse than TLS 1.2 resumption on LAN. I see on wire-shark that
> encrypted messages get exchanged in TLS 1.3 during handshake which are
> plaintext in TLS 1.2. I think that causes extra latency. So can we say
> that TLS 1.3 resumption is not recommended for LAN for performance
> enhancement when compared with TLS 1.2 resumption. On WAN, I see TLS
> 1.3 resumption at par with TLS 1.2 resumption and full handshake
> better for TLS 1.3.
>

It seems like it hasn't really sunk in for you that TLS 1.3 is a
seriously different protocol than TLS 1.2, and it provides stronger
security properties, remediating weaknesses of TLS 1.2.  So no, we
should not recommend TLS 1.2 resumption on the LAN -- we should
recommend the more secure option!  If you continue to believe that
latency trumps everything else, you could experiment with
SSL_OP_ALLOW_NO_DHE_KEX to cut out some of the heavier-weight asymmetric
crypto, though it looks like you'd want to patch
ssl/statem/extensions_clnt.c to not send TLSEXT_KEX_MODE_KE_DHE, as I
don't see a way to configure the server to prefer the non-DHE PSK key
exchange.

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

[openssl-users] Open ssl & Freeradius

[Seniha S . ÖZTEMİZ TULGAR]

Hello,

I installed the new version of freeradius and trying to configure it. My
windows10 clients gets authenticated but windows7 clients gets the
following errors. It seems that it is about openssl. Can you help me
regarding this problem. Any suggestions ?

Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: [eaptls verify] = ok
Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: Done initial handshake
Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: (other): before SSL
initialization
Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: TLS_accept: before SSL
initialization
Tue Jul 25 14:11:59 2017 : Debug: Ignoring cbtls_msg call with pseudo
content type 256, version 0
Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: TLS_accept: before SSL
initialization
Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: <<< recv TLS 1.2  [length
002d]
Tue Jul 25 14:11:59 2017 : Debug: Ignoring cbtls_msg call with pseudo
content type 256, version 0
Tue Jul 25 14:11:59 2017 : Debug: (1) eap_ttls: >>> send TLS 1.0 Alert
[length 0002], fatal handshake_failure
Tue Jul 25 14:11:59 2017 : ERROR: (1) eap_ttls: TLS Alert
write:fatal:handshake failure
Tue Jul 25 14:11:59 2017 : Error: tls: TLS_accept: Error in error
Tue Jul 25 14:11:59 2017 : ERROR: (1) eap_ttls: Failed in __FUNCTION__
(SSL_read): ../ssl/statem/statem_srvr.c[1404]:error:1417A0C1:SSL
routines:tls_post_process_client_hello:no shared cipher
Tue Jul 25 14:11:59 2017 : ERROR: (1) eap_ttls: System call (I/O) error (-1)
Tue Jul 25 14:11:59 2017 : ERROR: (1) eap_ttls: TLS receive handshake
failed during operation
Tue Jul 25 14:11:59 2017 : ERROR: (1) eap_ttls: [eaptls process] = fail
Tue Jul 25 14:11:59 2017 : ERROR: (1) eap: Failed continuing EAP TTLS (21)
session.  EAP sub-module failed

-- 
Kind regards,

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