Re: mutual-TLS / mTLS Example with certificate problem

[Raja Ashok]

Hi Andreas,

Below repo has examples to use OpenSSL for mTLS (mutual certificate
authentication) with sample certificates. You can refer this.

https://github.com/TalkWithTLS/TalkWithTLS/blob/master/src/sample/openssl_tls13_server_both_auth.c
https://github.com/TalkWithTLS/TalkWithTLS/blob/master/src/sample/openssl_tls13_client_both_auth.c

On Thu, May 7, 2020 at 12:36 AM Andreas Tengicki 
wrote:

> Hello,
>
> I can not find a working mutual-TLS server/client example on github or
> the whole internet. Only some example for pieces of code. Communication
> via socket without and with encryption (openSSL) is working, but with
> mTLS not. I believe that I theoretical understand mTLS, but the practice
> will not work.
>
> The whole (small) project is here:
> https://github.com/deckard-rick/mTLS-example
>
> Server Side
> =
>
> I initialize the SSL-context without errors with (sample, error handling
> is not in this email)
>
> SSL_CTX_set_ecdh_auto(srvCtx->ctx, 1);
> SSL_CTX_set_verify(srvCtx->ctx, SSL_VERIFY_PEER or
> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL);
> SSL_CTX_load_verify_locations(srvCtx->ctx,NULL,"../certs"); //
> SSL_CTX_use_certificate_chain_file(srvCtx->ctx,
> "../certs/server/ca.crt");
> SSL_CTX_use_certificate_file(srvCtx->ctx,
> "../certs/server/server.crt", SSL_FILETYPE_PEM);
> SSL_CTX_use_PrivateKey_file(srvCtx->ctx,
> "../certs/server/server.key", SSL_FILETYPE_PEM);
> SSL_CTX_check_private_key(srvCtx->ctx);
>
> the certificates are:
>
> ca.crt:  Version: 3 (0x2)
> Serial Number:
> 5a:fc:74:e6:28:28:0e:df:5b:7a:50:9e:a8:18:e6:04:42:f0:fd:8d
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN =
> 42CA
>  Validity  Not Before: May  6 09:21:23 2020 GMT  Not After : May  6
> 09:21:23 2022 GMT
>  Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN
> = 42CA
>
> server.crt: Version: 1 (0x0)
> Serial Number:
> 5f:6f:44:b5:27:47:f2:d2:fe:2b:21:5b:38:7d:e5:f6:e5:d9:c1:23
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN =
> 42CA
> Validity  Not Before: May  6 09:30:23 2020 GMT   Not After : May  6
> 09:30:23 2021 GMT
> Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN =
> debiandevdesktop01.sdctec.lokal
>
> debiandevdesktop01.sdctec.lokal is the FQDN of the development server
>
> Client Side
> =
>
> SSL_CTX_set_ecdh_auto(ctx, 1);
> SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);
> SSL_CTX_use_certificate_chain_file(ctx, "../certs/client/ca.crt");
> SSL_CTX_use_certificate_file(ctx, "../certs/client/client.crt",
> SSL_FILETYPE_PEM);
> SSL_CTX_use_PrivateKey_file(ctx, "../certs/client/client.key",
> SSL_FILETYPE_PEM);
>
> ca.crt:  (see server)
>
> client.crt: Version: 1 (0x0)
>Serial Number:
> 5f:6f:44:b5:27:47:f2:d2:fe:2b:21:5b:38:7d:e5:f6:e5:d9:c1:24
>Signature Algorithm: sha256WithRSAEncryption
>Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = 42CA
>Validity  Not Before: May  6 09:35:51 2020 GMT   Not After : May  6
> 09:35:51 2021 GMT
>Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN =
> CLIENT001
>
> Error:
> =
>
> If the client connects the server there are the following errors:
>
> server:
> 139918902234240:error:1416F086:SSL
> routines:tls_process_server_certificate:certificate verify
> failed:../ssl/statem/statem_clnt.c:1915:
>
> client:
> 139918902234240:error:1416F086:SSL
> routines:tls_process_server_certificate:certificate verify
> failed:../ssl/statem/statem_clnt.c:1915:
>
> I think, there is a problem with the certificates. But where is the
> problem and why?
>
> The statement to create the certificates are in the project ./certs/
> read.me
>
> Thanks for any help, I'm looking since days for a solution and I believe
> it is only a small bug.
>
> Best regards
>
>   Andreas
>
>
>

Using SSL_read and SSL_write on parallel threads

[Raja Ashok]

Hi All,

A TLS server application spawns 2 thread and handles 'n' number of TLS
clients. All connections SSL_read operations are performed on one thread
and SSL_write on another thread. To achieve this currently I lock the `SSL`
connection handle. This application uses TLSv1.2 and TLSv1.3.

My question is does anyone uses SSL_read and SSL_write in parallel thread
in much better way ?

Regards,
Raja Ashok

Usage of Secure C (memcpy_s, strcpy_s etc) functions on OpenSSL

[Raja ashok]

Hi All,

We are using OpenSSL in our projects and we found some of the C standard 
functions (like memcpy, strcpy) used in OpenSSL may induce security 
vulnerablities like buffer overflow. Currently we have not found any instances 
which causes such issues.

But we feel better to change these calls to C11 standard's secure functions 
like memcpy_s, strcpy_s etc. By defining a secure calls method (list of func 
pointers) and allowing application to register the method. I understand that 
this affects performance because of return value check added for _s calls, 
but this will make sure it removes buffer overflow kind of issues completely 
from code. And also currently using secure c calls is a general industry 
practice.

Please share your opinion on it, and if any discussion happened in OpenSSL 
coummunity to do this change in future.

Thanks in advance.
Raja Ashok

Usage of Secure C (memcpy_s, strcpy_s etc) functions on OpenSSL

[Raja ashok]

Hi All,

We are using OpenSSL in our projects and we found some of the C standard 
functions (like memcpy, strcpy) used in OpenSSL may induce security 
vulnerablities like buffer overflow. Currently we have not found any instances 
which causes such issues.

But we feel better to change these calls to C11 standard's secure functions 
like memcpy_s, strcpy_s etc. By defining a secure calls method (list of func 
pointers) and allowing application to register the method. I understand that 
this affects performance because of return value check added for _s calls, 
but this will make sure it removes buffer overflow kind of issues completely 
from code. And also currently using secure c calls is a general industry 
practice.

Please share your opinion on it, and if any discussion happened in OpenSSL 
community to do this change in future.

Thanks in advance.
Raja Ashok

Re: SSL_CTX_set1_curves to specify curves in Client Hello Supported Group Extension, not working

[Raja Ashok]

Hi,

Need to use *SSL_CTX_set1_curves_list()*, for ECC curves configuration
using string.

SSL_CTX_set1_curves_list(ctx, "P-521:P-384:P-256")

Regards,
R Ashok

On Tue, Nov 26, 2019 at 1:42 PM Rohit Kaushal 
wrote:

> Hi,
>
> I would like to ask if anyone here has actually been able to trim the EC
> Supported Groups in the Client Hello with a TLS-ECDHE cipher using the APIs
> described in the OpenSSL v1.0.2 manpage for SSL_CTX_set1_curves()
> 
>
>
>
> My shared objects are built using OpenSSL v1.0.2t with FIPS Object Module
> v2.0.5 . The TLS handshake pcap has always shown myCipher (
> "ECDHE-RSA-AES128-GCM-SHA256") in the Client Hello correctly, accompanied
> with 13 curves in the Supported Group Extension. However, enhancing SSL_CTX
> myCtx to restrict the curves to just 3 (P-521:P384:P256) still show the
> same 13 curves as in the pcap. The man page doesn't suggest nor do i see
> any reason why FIPS should prevent this from working.
>
>
> //existing working code
>
> if((myCtx = SSL_CTX_new(SSL_METHOD *)TLSv1_2_method()) == NULL)
>
>  return;
>
> if((SSL_CTX_set_cipher_list(myCtx, myCipher) != 1))
>
>  return;
>
>
>
> //enhancement, not working
>
> if(SSL_CTX_set1_curves(myCtx, "P-521:P-384:P-256", 3)) != 1))
>
>  return;
>
>
>
> The API returns 0 (suggesting no error), but pcap shows no change, i.e.
> still shows the std. 13 curves.
>
>
>
> Trying a code snippet involving SSL_CONF_cmd(myConfCtx, "-named-curve",
> "P-256") suggested in this link
> 
>  ,
> available prior to SSL_CTX_set1_curves() introduction in v1.0.2, didn’t
> help either.
>
>
> Thank you for any guidance you can provide.
>
> Rohit
>

RSA PSS RSAE Cert Generation

[Raja Ashok]

Hi All,

For using with TLS1.3, I am able to generate rsa_pss_pss cert (Both Public
key and Signature of RSA_PSS OID) with the below script.

https://github.com/raja-ashok/sample_certificates/blob/master/RSA_PSS_PSS_Certs/gen_rsa_cert.sh

Can some one help me to find out the command for generating rsa_pss_rsae
cert (Public key of rsaEncryption OID and Signature of RSA PSS OID) ?

Thanks in advance !
Raja Ashok

Re: Handling signature_algorithm extension on TLS1.3 server

[Raja Ashok]

>
> This was an area of some ambiguity in the TLSv1.2 spec where only
> signature_algorithms exists. I believe it was common practice for
> implementations to not check the signatures in certificates for
> conformance with
> this (certainly that is the way OpenSSL behaves). The TLSv1.3 spec seems
> to be
> more explicit about this. I would expect our TLSv1.2 implementation to
> continue
> to operate as it did before so this additional checking of signatures in
> certificates where only the signature_algorithms extensions is present
> should
> only apply to TLSv1.3.
>
> I don't see any code to do this in has_usable_cert so this looks like a
> potential bug. Although possibly it was left out on purpose.
>

Yes. Currently this check is missing for both TLSv1.2 and TLSv1.3. I feel
we may need to add for both TLSv1.2 and TLSv1.3, because TLSv1.2 RFC 5246
also mandates to do this check.

   If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by a
   hash/signature algorithm pair that appears in that extension.


Fix should be something like
https://github.com/raja-ashok/openssl/commit/2eb916d6048f54fd6109329d31850f8eb4407780

Atleast we should add this check for TLSv1.3. Otherwise cert with
rsa_pkcsv1_5_xxx signature getting selected even if client has not included
rsa_pkcsv1_5_xxx in signature_algorithm ext, but included rsa_pss_rsae_xxx.
This looks weird.

Apart from this I am having one more doubt, that TLSv1.3 RFC 8446 says
certificate with legacy signature(rsa_pkcsv1_5_sha1 and ecdsa_sha1) can be
selected if no other valid certificate present on TLS1.3 server. But in
tls_choose_sigalgs() function for TLSv1.3 we are currently skipping all
SHA1 based and RSA_PKCSv1_5 based signature algorithm. I feel instead of
avoiding we should consider as a low priority in this function for
selecting legacy certificates with rsa_pkcsv1_5 and ecdsa_sha1.


  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless
  no valid certificate chain can be produced without it (see
  Section 4.4.2.2 <https://tools.ietf.org/html/rfc8446#section-4.4.2.2>).




> Ben Kaduk may have a view on this who implemented this code:
>
>
> https://github.com/openssl/openssl/pull/5068/commits/e639c37bddea48334cb45d88d407c655641e1a35
>
>
And also requesting Ben Kaduk to put some light on it.

Re: Handling signature_algorithm extension on TLS1.3 server

[Raja Ashok]

Thanks for the detailed explanation.

So rsaEncryption cert can do both RSASSA-PKCS-v1_5 and RSASSA-PSS type
signature. And also the digital signature present on the cert can be of
type RSASSA-PKCS-v1_5 or RSASSA-PSS.

Currently in 1.1.1c's has_usable_cert() function, digital signature
(Issuer's signature) present on rsaEncryption cert type is not checked. So
if TLS1.3 client sends rsa_pss_rsae_xxx in "signature_algorithm" extension
and if the server's rsaEncrypted cert has digital signature of type
RSASSA-PKCS-v1_5, then it should not use that certificate but it is using
currently.

And also the hash algorithm used on rsaEncryption cert's digital signature
is not checked with "signature_algorithm" extension received from client.
If TLS1.3 client sends rsa_pss_rsae_sha384 and rsa_pss_rsae_sha512 in
"signature_algorithm" extension, and if server has a rsaEncrypted cert with
signature of type rsa_pss_rsae_sha256 then it should not use that
certificate, but it is using currently.


On Thu, Jun 6, 2019 at 9:11 PM Matt Caswell  wrote:

>
>
> On 06/06/2019 16:15, Raja Ashok wrote:
> > Hi,
> >
> > Currently has_usable_cert() function is called on tls_choose_sigalg() to
> find
> > out the suitable certificate available. But currently rsa_pkcs1_xxx and
> > rsa_pss_rsae_xxx certs are stored on same index SSL_PKEY_RSA. Because of
> this it
> > may ends in choosing rsa_pkcs1_xxx cert for rsa_pss_rsae_xxx extension.
> Is this
> > behaviour correct ?
>
> There are two things to consider:
>
> 1) The OID in the RSA cert, which can be one of rsaEncryption or
> RSASSA-PSS. The
> former is for "traditional" RSA certs, whilst the latter *only* allows use
> of
> the key for signing (it cannot be used for encryption).
>
> 2) The type of signing in use, e.g. RSASSA-PKCS-v1_5 or RSASSA-PSS.
>
> rsaEncryption certs are capable of doing *either* form of signing, whilst
> RSASSA-PSS certs can only do PSS signing.
>
> We store rsaEncryption certs under the SSL_PKEY_RSA index, and RSASSA-PSS
> certs
> under the SSL_PKEY_RSA_PSS_SIGN index.
>
> TLSv1.2 and below signs handshake messages using PKCS v1.5. which
> corresponds to
> these signature algorithms:
>
>   rsa_pkcs1_sha256(0x0401)
>   rsa_pkcs1_sha384(0x0501)
>   rsa_pkcs1_sha512(0x0601)
>
> These sig algs cannot be used in TLSv1.3 for signing handshake messages,
> although they may appear in a ClientHello for backwards compatibility with
> TLSv1.2. You can only use these sig algs with "traditional" RSA certs (not
> PSS
> RSA certs).
>
> TLSv1.3 signs handshake messages using PSS which corresponds to these
> signature
> algorithms for "traditional" (rsaEncryption) certs:
>
>   rsa_pss_rsae_sha256(0x0804)
>   rsa_pss_rsae_sha384(0x0805)
>   rsa_pss_rsae_sha512(0x0806)
>
> Or these signature algorithms for PSS certs:
>
>   rsa_pss_pss_sha256(0x0809)
>   rsa_pss_pss_sha384(0x080a)
>   rsa_pss_pss_sha512(0x080b)
>
> Therefore it is perfectly correct behaviour that a cert stored under the
> SSL_PKEY_RSA index could be used for signing handshake message using either
> rsa_pkcs1_xxx or for rsa_pss_rsae_xxx. The former is used in TLSv1.2 and
> the
> latter is used in TLSv1.3.
>
> Matt
>

Handling signature_algorithm extension on TLS1.3 server

[Raja Ashok]

Hi,

Currently has_usable_cert() function is called on tls_choose_sigalg() to
find out the suitable certificate available. But currently rsa_pkcs1_xxx
and rsa_pss_rsae_xxx certs are stored on same index SSL_PKEY_RSA. Because
of this it may ends in choosing rsa_pkcs1_xxx cert for rsa_pss_rsae_xxx
extension. Is this behaviour correct ?

As per my understanding a new index should be created like
SSL_PKEY_RSA_PSS_RSAE_SIGN for rsa_pss_rsae_xxx type certs.

Regards,
Raja Ashok

Difficulty in understanding TLS1.3 APIs in OpenSSL 1.1.1

[Raja Ashok]

Hi All,

I feel like some TLS 1.3 configuration APIs in OpenSSL 1.1.1 are
uncomfortable in using it.

*1) Configuring Cipher Suit:* There is a new API for configuring TLS1.3
cipher suite, which is *SSL_set_ciphersuites()*. But calling only
*SSL_set_ciphersuites()* does not work. Need to call old API
*SSL_set_cipher_list()* first and then   *SSL_set_ciphersuites()*.

*2) Configuring supported groups and temp ECDHE:* Configuring temp ECDHE
using *SSL_set_tmp_ECDH()* configures the corresponding curve ID as
supported groups. So calling first *SSL_set1_groups()* and then calling*
SSL_set_tmp_ECDH()* resets the configured groups using *SSL_set1_groups()*.

I feel the configuration APIs introduced in TLS1.3 are little confusing and
it should be used in certain order to achieve the required configuration.

Can some one try to clarify me these API behaviours or is my understanding
of using these API is incorrect ?

Regards
R Ashok

DTLSv1_listen Nonblock IO failure not returning SSL_ERROR_WANT_READ

[Raja Ashok]

Hi,

When Nonblock IO failure happens on DTLSv1_listen() its returning 0. But
SSL_get_error() is not returning SSL_ERROR_WANT_READ. Instead it
returns SSL_ERROR_SYSCALL.

Can someone tell its intentionally kept this behaviour ?

Thanks & Regards,
Ashok,
Huawei Technologies, India

Re: [openssl-users] In ssl3_write_bytes, some checks related to hanlding write failure are missing

[Raja ashok]

Hi All,

In ssl3_write_bytes, if (len < tot) we are returning failure with 
SSL_R_BAD_LENGTH error. In this place I hope we should set “tot” back to 
“s->s3->wnum”. Otherwise when application calls back SSL_write with correct 
buffer, it causes serious problem (“tot” is 0 and iLeft is not NULL). I hope we 
should do like below.

if (len < tot) {
s->s3->wnum = tot;
SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
   return (-1);
}

And also we should do one additional check for “len” as mentioned in my 
previous mail.

if ((len < tot) || ((tot != 0) && (len < (tot + s->s3->wpend_tot{
s->s3->wnum = tot;
SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
   return (-1);
}

Regards,
Ashok

____
[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

From: Raja ashok
Sent: 27 March 2017 13:55
To: 'openssl-users@openssl.org'; 'openssl-...@openssl.org'
Subject: In ssl3_write_bytes, some checks related to hanlding write failure are 
missing

Hi,

I feel there is a check missing in ssl3_write_bytes, in case of handling write 
failure.

Consider SSL_write is called with 2 bytes buffer, then internally in 
ssl3_write_bytes we try to send it as two record (16384 and 3616). If TCP send 
failed for the second record then we store the states internally (wnum, 
wpend_tot and wpend_buf) and return back the result.

Later application has to call SSL_write with same buffer, if it calls with 
different buffer of length 100 byte then we fail that in ssl3_write_bytes using 
the check (len < tot).

But consider application calls with buffer of size 18000 bytes and 
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is enabled. Then (len < tot) will not 
succeed as tot is 16384. Then it will call ssl3_write_pending to send the 
remaining 3616 record. If it succeeds we are incrementing tot, (tot += i). Now 
tot will have 2.

Later there is a check (tot == len), this will not succeed. Then directly we 
are doing n = (len - tot), this will overflow and store a value close to 2^32 
in n. Then it will cause out of bound access to the application buffer "buf".

I hope we should have one more check (len < (tot + s->s3->wpend_tot)) before 
calling ssl3_write_pending.

if ((len < tot) || (len < (tot + s->s3->wpend_tot))){
SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
return (-1);
}

Note : I am referring 1.0.2k version of OpenSSL.

Regards,
Ashok


[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

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

[openssl-users] In ssl3_write_bytes, some checks related to hanlding write failure are missing

[Raja ashok]

Hi,

I feel there is a check missing in ssl3_write_bytes, in case of handling write 
failure.

Consider SSL_write is called with 2 bytes buffer, then internally in 
ssl3_write_bytes we try to send it as two record (16384 and 3616). If TCP send 
failed for the second record then we store the states internally (wnum, 
wpend_tot and wpend_buf) and return back the result.

Later application has to call SSL_write with same buffer, if it calls with 
different buffer of length 100 byte then we fail that in ssl3_write_bytes using 
the check (len < tot).

But consider application calls with buffer of size 18000 bytes and 
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is enabled. Then (len < tot) will not 
succeed as tot is 16384. Then it will call ssl3_write_pending to send the 
remaining 3616 record. If it succeeds we are incrementing tot, (tot += i). Now 
tot will have 2.

Later there is a check (tot == len), this will not succeed. Then directly we 
are doing n = (len - tot), this will overflow and store a value close to 2^32 
in n. Then it will cause out of bound access to the application buffer "buf".

I hope we should have one more check (len < (tot + s->s3->wpend_tot)) before 
calling ssl3_write_pending.

if ((len < tot) || (len < (tot + s->s3->wpend_tot))){
SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
return (-1);
}

Note : I am referring 1.0.2k version of OpenSSL.

Regards,
Ashok

____
[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

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

[openssl-users] DTLS is not sending alert in case of BAD CCS

[Raja ashok]

Hi All,

Looks like there is a typo mistake in dtls1_read_bytes, because of this alert 
is not send for bad CCS.

In dtls1_read_bytes, incase of bad change cipher spec we are setting alert code 
(SSL_AD_ILLEGAL_PARAMETER) to variable “i” and doing “goto err”. I feel we are 
trying to send alert in this case, so we need to set the alert in “al” and do 
“goto f_err”.

In case of TLS we are sending alert.

Note : I am referring 1.0.2.k version of OpenSSL

Regards,
Ashok


[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

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

[openssl-users] Doubt regarding Export keying material

[Raja ashok]

Hi All,

I am having a doubt in usage of Exporting keying material API 
(SSL_export_keying_material) in OpenSSL. Please provide your suggestions.

As per Section 4 in RFC 5705, context length should be passed as uint16_t to 
PRF function. In that case we should allow only upto max of 2^16 (65535). So 
user should not pass more than 65535 value to “plen” in 
SSL_export_keying_material right ?

Please provide your valuable suggestion on this. I am referring 1.0.2k version 
of OpenSSL.

Thanks & Regards,
Ashok


[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

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

[openssl-users] Doubt regarding process of invalid [D]TLS record

[Raja ashok]

Hi All,

In dtls1_get_record(), we are calling ssl3_read_n to get 13 bytes of DTLS 
record header from socket and then based on the length in record header, we 
again call ssl3_read_n to get record payload from socket. Here we are handling 
invalid record, like length less 13 bytes or invalid version in record header 
or invalid epoch etc. If such invalid record comes then we are dropping that 
record and going to read again from socket, by calling ssl3_read_n again. If a 
peer is continuously sending invalid DTLS record, then our execution will be 
just running inside dtls1_get_record function. It wont come out of that 
function. So if a malicious peer wants to block our DTLS connection thread, 
then it can do by simply sending invalid DTLS record continuously. This 
behaviour would be same for both synchronous and asynchronous UDP sockets. This 
will simply block the application for long time, for the API SSL_connect, 
SSL_accept or SSL_read.

I feel here we should not block the application call for long time, we should 
have some mechanism to fail the connection and inform application if we get 
invalid DTLS record continuously. For example, if we receive around 100 invalid 
DTLS record continuously, then we should come out of this "goto" in 
dtls1_get_record and return failure to application. And also we can send alert 
to peer and close the DTLS connection.

For similar issue in ssl3_get_record(), we are having a max 
limit(MAX_EMPTY_RECORDS) for the received empty record. I feel similar limit 
should be there for invalid DTLS record in dtls1_get_record.

Similarly in ssl3_get_message and dtls1_get_message_fragment, if we receive 
Hello request message continuously, then we are just dropping and continuously 
going back to read on socket. This also may cause a long time block to 
application, for the API SSL_connect if malicious peer is continuously sending 
Hello request msg.

I feel blocking of application call for a long time should be avoided. Please 
check this and clarify me, if my understanding is wrong.

Note : I am referring openssl-1.0.2k and asking this doubt.

Regards,
Ashok


[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

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