Re: [TLS] weird DHE params p length in TLSv1.2

one correction: > cipher suite used: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f) It is actually TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) On Tue, 17 Oct 2023 at 13:55, M K Saravanan wrote: > Hi, > > I found a weird packet capture of DHE key exchange. > > C --> S >

[TLS] weird DHE params p length in TLSv1.2

Hi, I found a weird packet capture of DHE key exchange. C --> S TLSv1.2 cipher suite used: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f) ServerKeyExchange message is sending: p length: 257 whereas pubkey length is: 256 256 means 256*8 = 2048 bit DHE key size. I am assuming, generally when

[TLS] doubt - what to do if a CA do not renew their expired cert?

Hi, I have a layman doubt. While working on a project, recently I discovered a list of CA cert which got expired. I am not responsible for sites using those cert. But my end users said sites using those certs are failing due to expired cert. So I visited the official CA website to download

[TLS] Does TLS support ECDHE based SEED cipher suites?

Hi, https://datatracker.ietf.org/doc/html/rfc4162#section-3.3 says the following SEED cipher suites are supported for TLS: == CipherSuite TLS_RSA_WITH_SEED_CBC_SHA = { 0x00, 0x96}; CipherSuite TLS_DH_DSS_WITH_SEED_CBC_SHA = { 0x00, 0x97}; CipherSuite

Re: [TLS] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange?

c3447#section-8.2.2 > https://tools.ietf.org/html/rfc8017#section-8.2.1 > https://tools.ietf.org/html/rfc8017#section-8.2.2 > > > On Wed, Feb 12, 2020 at 1:27 AM M K Saravanan wrote: > >> Hi, >> >> I recently encountered the below issue: >> &g

[TLS] TLS 1.2 - is it allowed to strip the leading zero byte(s) in RSA signature in ServerKeyExchange?

Hi, I recently encountered the below issue: TLS1.2 ECDHE_RSA server certificate: 2048-bit RSA (= 256 bytes) ServerKeyExchange hash/sign algorithm: rsa_pkcs1_sha1 The server was sending the ServerKeyExchange with 255 byte as length for the RSA signature (i.e. the leading zero was stripped)

Re: [TLS] TLSv1.2 - Is zero signature allowed in client CertificateVerify message?

). Looks like a bug on the client side then. with regards, Saravanan On Tue, 3 Sep 2019 at 23:40, David Benjamin wrote: > The client should just abort the handshake and probably send an alert like > internal_error since it cannot usefully proceed. > > On Tue, Sep 3, 2019 at 11:27 AM M

Re: [TLS] TLSv1.2 - Is zero signature allowed in client CertificateVerify message?

condition? Is this allowed in TLS 1.2 RFC? with regards, Saravanan On Tue, 3 Sep 2019 at 22:36, Richard Barnes wrote: > I don't believe that's a valid signature according to rsa_pkcs1_sha256, so > yeah, this is probably an error. > --Richard > > On Sun, Sep 1, 2019 at 11:33 P

[TLS] TLSv1.2 - Is zero signature allowed in client CertificateVerify message?

Hi, Is zero signature allowed in client CertificateVerify message (I am guessing may be to indicate error condition??). I don't see any thing related to zero signature in the TLS 1.2 RFC (or may be I am not looking into the right section?) Today I saw a packet like this and server was

[TLS] TLSv1.3 - purpose of _0 in {client, server}_application_traffic_secret_0

Hi, In TLSv1.3, what is the purpose of _0 suffix in the following: client_application_traffic_secret_0 server_application_traffic_secret_0 with regards, Saravanan ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS1.3 HkdfLabel - value of label<0..6> ?

On Sun, 31 Mar 2019 at 21:46, Ilari Liusvaara wrote: > The syntax "opaque label<7..255>" means that label is octet string of > at least 7 and at most 255 octets, and that its length is encoded using > 1 octet. The string "tls13 " is 6 octets long, so that impiles that > Label is at least 1 octet

[TLS] TLS1.3 HkdfLabel - value of label<0..6> ?

Hi, https://tools.ietf.org/html/rfc8446 7.1. Key Schedule The key derivation process makes use of the HKDF-Extract and HKDF-Expand functions as defined for HKDF [RFC5869], as well as the functions defined below: HKDF-Expand-Label(Secret, Label, Context, Length) =

Re: [TLS] regd. signature algorithm 0x0804 (rsa_pss_rsae_sha256) use in TLSv1.2 CertificateVerify

Thanks David. with regards, Saravanan. On Wed, 21 Nov 2018 at 02:07, David Benjamin wrote: > > Yes, this is correct. > > On Tue, Nov 20, 2018 at 10:35 AM M K Saravanan wrote: >> >> Hi, >> >> RFC8446: >> ===

Re: [TLS] regd. signature algorithm 0x0804 (rsa_pss_rsae_sha256) use in TLSv1.2 CertificateVerify

is RSA. 0x0804 = rsa_pss_rsae_sha256 Can some one please confirm whether my understanding is correct? with regards, Saravanan On Wed, 21 Nov 2018 at 00:27, M K Saravanan wrote: > > Hi, > > If a TLSv1.2 Certificate Request message contains 0x0804 > (rsa_pss_rsae_sha256) as one o

[TLS] regd. signature algorithm 0x0804 (rsa_pss_rsae_sha256) use in TLSv1.2 CertificateVerify

Hi, If a TLSv1.2 Certificate Request message contains 0x0804 (rsa_pss_rsae_sha256) as one of the supported signature algorithms, can a client sign the CertificateVerify message using that algorithm? (client cert is RSA). Is it allowed in TLSv1.2? with regards, Saravanan

[TLS] TLSv1.3 - Draft 24 - small typo need correction

Hi, In TLSv1.3, draft 24, there is a small typographical error. It needs to be corrected. (1) Appendix D. Backward Compatibility Second Paragraph. Second sentence. There is a double "and". /* Original */ = Servers can also handle clients trying to use future versions of TLS as