Re: Default value of a session resumption timeout (300 seconds vs 7200 seconds)
Even if session life time is proposed by server.. if client has a
configuration local configuration shouldn't we pick the minimum of what
server is configuring and what client is configured with?.
If we don't have this option in openssl should we have this change.. any
one interested to work along with me?.
-thanks
harish
On Tue, Jan 26, 2021 at 11:43 PM Harish Kulkarni
wrote:
> Thank you both for bringing this to my attention, your points are
> invaluable.
>
> If this is something which gets set from server on client side. can client
> override this?. Can i change this to something less and try?. Has anyone
> tried?.
>
> Whats the option in openssl.conf or some other place?.
>
> -thanks
> harish
>
>
> On Mon, Jan 25, 2021 at 11:08 PM Matt Caswell wrote:
>
>>
>>
>> On 23/01/2021 15:22, John Thoe wrote:
>> > Hi list,
>> >
>> > The session reuse question posted on the mailing list earlier
>> > (
>> https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html)
>> > reminded of a somewhat similar question I have.
>> >
>> > As per the docs,
>> > https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html
>> ,
>> > it says the default value is 300 seconds for which a session resuse
>> > will be accepted. The docs say that it is the same for all
>> > protocols.
>> >
>> > However I tried it with my setup where I didn't explicitly set the
>> > timeout and I am getting 7200 seconds as the default value. s_client
>> > output: TLS session ticket lifetime hint: 7200 (seconds). My client
>> > openssl.conf has no setting override (not that it should matter
>> > because this is a server preference). No OpenSSL settings on the
>> > server have been modified as well.
>>
>> Looks to me like the docs are wrong. They probably should say 7200.
>>
>>
>> >
>> > In ssl/ssl_sess.c#L80, the code matches the document: ss->timeout =
>> > 60 * 5 + 4; /* 5 minute timeout by default */ ... (with additional
>> > four seconds?)
>>
>>
>> This gets set during construction and then later overwritten when we
>> actually get a new session via "ssl_get_new_session":
>>
>> /* If the context has a default timeout, use it */
>> if (s->session_ctx->session_timeout == 0)
>> ss->timeout = SSL_get_default_timeout(s);
>> else
>> ss->timeout = s->session_ctx->session_timeout;
>>
>> In most cases SSL_get_default_timeout() calls tls1_default_timeout() (it
>> can end up somewhere different for certain protocol versions - but all
>> the different variants are the same!):
>>
>> long tls1_default_timeout(void)
>> {
>> /*
>> * 2 hours, the 24 hours mentioned in the TLSv1 spec is way too long
>> for
>> * http, the cache would over fill
>> */
>> return (60 * 60 * 2);
>> }
>>
>> 60 * 60 * 2 = 7200
>>
>>
>> Matt
>>
>>
Re: UI_METHOD functions not being invoked for smart card
Hi,
I looked for "NO_UI" in the source code but did not find any
references to it. I'll take a closer look and see if I can find some
other flag, which disables the UI_METHOD function calls.
By the way, I found your code for this in eap-tls.c very helpful and
easy to follow. :) I did have to make minor modifications for it to
compile with the Visual Studio C++ compiler, though.
Thanks,
George
On 2021-01-26 4:29 a.m., Jan Just Keijser wrote:
On 26/01/21 05:28, George wrote:
Hi,
I'm trying to get OpenSSL 1.0.2u with the FIPS Object Module
2.0.16 in Windows 10 to prompt the user for a smart card's PIN
number every time the application is launched. However, I cannot seem
to get it to work. My UI_METHOD callback functions are not being invoked.
I'm using the following code as a reference:
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c
I tried the following:
UI_METHOD* transfer_pin = UI_create_method("transfer_pin");
int writer (UI *ui, UI_STRING *uis)
{
PW_CB_DATA* cb_data = (PW_CB_DATA*)UI_get0_user_data(ui);
UI_set_result(ui, uis, cb_data->password);
return 1;
};
int stub (UI* ui) {return 1;};
int stub_reader (UI *ui, UI_STRING *uis) {return 1;};
UI_method_set_writer(transfer_pin, writer);
UI_method_set_opener(transfer_pin, stub);
UI_method_set_closer(transfer_pin, stub);
UI_method_set_flusher(transfer_pin, stub);
UI_method_set_reader(transfer_pin, stub_reader);
pkey = ENGINE_load_private_key(pkey_engine, pkey_identifier,
transfer_pin, &cb_data);
However, none of the callback functions "writer", "stub", or
"stub_reader" actually get called. Do I need to do anything else to
enable this functionality? I would like to force the user to enter
PIN number every time.
this depends on how openssl for windows was built ; some non-UNIX
builds set the flag OPENSSL_NO_UI_CONSOLE (or possibly OPENSSL_NO_UI)
in which case all UI_methods are effectively disabled. If this flag is
set for your build then you will have to rebuild OpenSSL.
Apart from that, that code snippet above is not the cleanest code I
have ever written - some C/C++ compilers do not like functions
defined insides an "if { } " block; you might have to take the
function "int writer { } " outside of the "if { } " block.
HTH,
JJK
Re: PKCS12 APIs with fips 3.0
You could set the default property query to "?fips=yes". This will prefer FIPS algorithms over any others but will not prevent other algorithms from being fetched. Pauli On 27/1/21 10:47 am, Zeke Evans wrote: I understand that PKCS12 cannot be implemented in the fips provider but I'm looking for a suitable workaround, particularly something that is close to the same behavior as 1.0.2 with the fips 2.0 module. In my case, the default provider is loaded but I am calling EVP_set_default_properties(NULL, "fips=yes"). I can wrap calls to the PKCS12 APIs and momentarily allow non-fips algorithms (ie: "fips=no" or "provider=default") but that prevents the PKCS12 implementation from using the crypto implementations in the fips provider. Is there a property string or some other way to allow PKCS12KDF in the default provider as well as the crypto methods in the fips provider? I have tried "provider=default,fips=yes" but that doesn't seem to work. Using the default provider is probably a reasonable workaround for reading in PKCS12 files in order to maintain backwards compatibility. Is there a recommended method going forward that would allow reading and writing to a key store while only using the fips provider? Thanks, Zeke Evans Micro Focus -Original Message- From: openssl-users On Behalf Of Dr Paul Dale Sent: Tuesday, January 26, 2021 5:22 PM To: openssl-users@openssl.org Subject: Re: PKCS12 APIs with fips 3.0 I'm not even sure that NIST can validate the PKCS#12 KDF. If it can't be validated, it doesn't belong in the FIPS provider. Pauli On 26/1/21 10:48 pm, Tomas Mraz wrote: On Tue, 2021-01-26 at 11:45 +, Matt Caswell wrote: On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote: On 2021-01-25 17:53, Zeke Evans wrote: Hi, Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse, PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips provider. It looks like that is because they try to load PKCS12KDF which is not implemented in the fips provider. These were all working in 1.0.2 with the fips 2.0 module. Will they be supported in 3.0 with fips? If not, is there a way for applications running in fips approved mode to support the same functionality and use existing stores/files that contain PKCS12 objects? This is an even larger issue: Is OpenSSL 3.x so badly designed that the "providers" need to separately implement every standard or non-standard combination of algorithm invocations? In a properly abstracted design PKCS12KDF would be implemented by invoking general EVP functions for underlying algorithms, which would in turn invoke the provider versions of those algorithms. This is exactly the way it works. The implementation of PKCS12KDF fetches the underlying digest algorithm using whatever providers it has available. So, for example, if the PKCS12KDF implementation needs to use SHA256, then it will fetch an available implementation for it - and that implementation may come from the FIPS provider (or any other provider). However, in 3.0, KDFs are themselves fetchable cryptographic algorithms implemented by providers. The FIPS module implements a set of KDFs - but PKCS12KDF is not one of them. Its only available from the default provider. So, the summary is, while you can set things up so that all your crypto, including any digests used by the PKCS12KDF, all come from the FIPS provider, there is no getting away from the fact that you still need to have the default provider loaded in order to have an implementation of the PKCS12KDF itself - which will obviously be outside the module boundary. There aren't any current plans to bring the implementation of PKCS12KDF inside the FIPS module. I don't know whether that is feasible or not. IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS approved KDF algorithm. Besides that KDF should not IMO be needed for "modern" PKCS12 files. I need to test that though.
RE: PKCS12 APIs with fips 3.0
I understand that PKCS12 cannot be implemented in the fips provider but I'm looking for a suitable workaround, particularly something that is close to the same behavior as 1.0.2 with the fips 2.0 module. In my case, the default provider is loaded but I am calling EVP_set_default_properties(NULL, "fips=yes"). I can wrap calls to the PKCS12 APIs and momentarily allow non-fips algorithms (ie: "fips=no" or "provider=default") but that prevents the PKCS12 implementation from using the crypto implementations in the fips provider. Is there a property string or some other way to allow PKCS12KDF in the default provider as well as the crypto methods in the fips provider? I have tried "provider=default,fips=yes" but that doesn't seem to work. Using the default provider is probably a reasonable workaround for reading in PKCS12 files in order to maintain backwards compatibility. Is there a recommended method going forward that would allow reading and writing to a key store while only using the fips provider? Thanks, Zeke Evans Micro Focus -Original Message- From: openssl-users On Behalf Of Dr Paul Dale Sent: Tuesday, January 26, 2021 5:22 PM To: openssl-users@openssl.org Subject: Re: PKCS12 APIs with fips 3.0 I'm not even sure that NIST can validate the PKCS#12 KDF. If it can't be validated, it doesn't belong in the FIPS provider. Pauli On 26/1/21 10:48 pm, Tomas Mraz wrote: > On Tue, 2021-01-26 at 11:45 +, Matt Caswell wrote: >> >> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote: >>> On 2021-01-25 17:53, Zeke Evans wrote: Hi, Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse, PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips provider. It looks like that is because they try to load PKCS12KDF which is not implemented in the fips provider. These were all working in 1.0.2 with the fips 2.0 module. Will they be supported in 3.0 with fips? If not, is there a way for applications running in fips approved mode to support the same functionality and use existing stores/files that contain PKCS12 objects? >>> This is an even larger issue: Is OpenSSL 3.x so badly designed that >>> the "providers" need to separately implement every standard or >>> non-standard combination of algorithm invocations? >>> >>> In a properly abstracted design PKCS12KDF would be implemented by >>> invoking general EVP functions for underlying algorithms, which >>> would in turn invoke the provider versions of those algorithms. >> >> This is exactly the way it works. The implementation of PKCS12KDF >> fetches the underlying digest algorithm using whatever providers it >> has available. So, for example, if the PKCS12KDF implementation needs >> to use SHA256, then it will fetch an available implementation for it >> - and that implementation may come from the FIPS provider (or any >> other provider). >> >> However, in 3.0, KDFs are themselves fetchable cryptographic >> algorithms implemented by providers. The FIPS module implements a set >> of KDFs - but PKCS12KDF is not one of them. Its only available from >> the default provider. >> >> So, the summary is, while you can set things up so that all your >> crypto, including any digests used by the PKCS12KDF, all come from >> the FIPS provider, there is no getting away from the fact that you >> still need to have the default provider loaded in order to have an >> implementation of the PKCS12KDF itself - which will obviously be >> outside the module boundary. >> >> There aren't any current plans to bring the implementation of >> PKCS12KDF inside the FIPS module. I don't know whether that is >> feasible or not. > > IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS > approved KDF algorithm. Besides that KDF should not IMO be needed for > "modern" PKCS12 files. I need to test that though. >
Re: PKCS12 APIs with fips 3.0
I'm not even sure that NIST can validate the PKCS#12 KDF. If it can't be validated, it doesn't belong in the FIPS provider. Pauli On 26/1/21 10:48 pm, Tomas Mraz wrote: On Tue, 2021-01-26 at 11:45 +, Matt Caswell wrote: On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote: On 2021-01-25 17:53, Zeke Evans wrote: Hi, Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse, PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips provider. It looks like that is because they try to load PKCS12KDF which is not implemented in the fips provider. These were all working in 1.0.2 with the fips 2.0 module. Will they be supported in 3.0 with fips? If not, is there a way for applications running in fips approved mode to support the same functionality and use existing stores/files that contain PKCS12 objects? This is an even larger issue: Is OpenSSL 3.x so badly designed that the "providers" need to separately implement every standard or non-standard combination of algorithm invocations? In a properly abstracted design PKCS12KDF would be implemented by invoking general EVP functions for underlying algorithms, which would in turn invoke the provider versions of those algorithms. This is exactly the way it works. The implementation of PKCS12KDF fetches the underlying digest algorithm using whatever providers it has available. So, for example, if the PKCS12KDF implementation needs to use SHA256, then it will fetch an available implementation for it - and that implementation may come from the FIPS provider (or any other provider). However, in 3.0, KDFs are themselves fetchable cryptographic algorithms implemented by providers. The FIPS module implements a set of KDFs - but PKCS12KDF is not one of them. Its only available from the default provider. So, the summary is, while you can set things up so that all your crypto, including any digests used by the PKCS12KDF, all come from the FIPS provider, there is no getting away from the fact that you still need to have the default provider loaded in order to have an implementation of the PKCS12KDF itself - which will obviously be outside the module boundary. There aren't any current plans to bring the implementation of PKCS12KDF inside the FIPS module. I don't know whether that is feasible or not. IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS approved KDF algorithm. Besides that KDF should not IMO be needed for "modern" PKCS12 files. I need to test that though.
Re: Default value of a session resumption timeout (300 seconds vs 7200 seconds)
Thank you both for bringing this to my attention, your points are
invaluable.
If this is something which gets set from server on client side. can client
override this?. Can i change this to something less and try?. Has anyone
tried?.
Whats the option in openssl.conf or some other place?.
-thanks
harish
On Mon, Jan 25, 2021 at 11:08 PM Matt Caswell wrote:
>
>
> On 23/01/2021 15:22, John Thoe wrote:
> > Hi list,
> >
> > The session reuse question posted on the mailing list earlier
> > (
> https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html)
> > reminded of a somewhat similar question I have.
> >
> > As per the docs,
> > https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html,
> > it says the default value is 300 seconds for which a session resuse
> > will be accepted. The docs say that it is the same for all
> > protocols.
> >
> > However I tried it with my setup where I didn't explicitly set the
> > timeout and I am getting 7200 seconds as the default value. s_client
> > output: TLS session ticket lifetime hint: 7200 (seconds). My client
> > openssl.conf has no setting override (not that it should matter
> > because this is a server preference). No OpenSSL settings on the
> > server have been modified as well.
>
> Looks to me like the docs are wrong. They probably should say 7200.
>
>
> >
> > In ssl/ssl_sess.c#L80, the code matches the document: ss->timeout =
> > 60 * 5 + 4; /* 5 minute timeout by default */ ... (with additional
> > four seconds?)
>
>
> This gets set during construction and then later overwritten when we
> actually get a new session via "ssl_get_new_session":
>
> /* If the context has a default timeout, use it */
> if (s->session_ctx->session_timeout == 0)
> ss->timeout = SSL_get_default_timeout(s);
> else
> ss->timeout = s->session_ctx->session_timeout;
>
> In most cases SSL_get_default_timeout() calls tls1_default_timeout() (it
> can end up somewhere different for certain protocol versions - but all
> the different variants are the same!):
>
> long tls1_default_timeout(void)
> {
> /*
> * 2 hours, the 24 hours mentioned in the TLSv1 spec is way too long
> for
> * http, the cache would over fill
> */
> return (60 * 60 * 2);
> }
>
> 60 * 60 * 2 = 7200
>
>
> Matt
>
>
Re: PKCS12 APIs with fips 3.0
On Tue, 2021-01-26 at 11:45 +, Matt Caswell wrote: > > On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote: > > On 2021-01-25 17:53, Zeke Evans wrote: > > > Hi, > > > > > > > > > > > > Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse, > > > PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips > > > provider. It looks like that is because they try to load > > > PKCS12KDF > > > which is not implemented in the fips provider. These were all > > > working > > > in 1.0.2 with the fips 2.0 module. Will they be supported in 3.0 > > > with > > > fips? If not, is there a way for applications running in fips > > > approved mode to support the same functionality and use existing > > > stores/files that contain PKCS12 objects? > > > > > > > > > > > This is an even larger issue: Is OpenSSL 3.x so badly designed > > that the "providers" need to separately implement every standard > > or non-standard combination of algorithm invocations? > > > > In a properly abstracted design PKCS12KDF would be implemented by > > invoking general EVP functions for underlying algorithms, which > > would in turn invoke the provider versions of those algorithms. > > This is exactly the way it works. The implementation of PKCS12KDF > fetches the underlying digest algorithm using whatever providers it > has > available. So, for example, if the PKCS12KDF implementation needs to > use > SHA256, then it will fetch an available implementation for it - and > that > implementation may come from the FIPS provider (or any other > provider). > > However, in 3.0, KDFs are themselves fetchable cryptographic > algorithms > implemented by providers. The FIPS module implements a set of KDFs - > but > PKCS12KDF is not one of them. Its only available from the default > provider. > > So, the summary is, while you can set things up so that all your > crypto, > including any digests used by the PKCS12KDF, all come from the FIPS > provider, there is no getting away from the fact that you still need > to > have the default provider loaded in order to have an implementation > of > the PKCS12KDF itself - which will obviously be outside the module > boundary. > > There aren't any current plans to bring the implementation of > PKCS12KDF > inside the FIPS module. I don't know whether that is feasible or not. IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS approved KDF algorithm. Besides that KDF should not IMO be needed for "modern" PKCS12 files. I need to test that though. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
Re: PKCS12 APIs with fips 3.0
On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote: > On 2021-01-25 17:53, Zeke Evans wrote: >> >> Hi, >> >> >> >> Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse, >> PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips >> provider. It looks like that is because they try to load PKCS12KDF >> which is not implemented in the fips provider. These were all working >> in 1.0.2 with the fips 2.0 module. Will they be supported in 3.0 with >> fips? If not, is there a way for applications running in fips >> approved mode to support the same functionality and use existing >> stores/files that contain PKCS12 objects? >> >> >> > This is an even larger issue: Is OpenSSL 3.x so badly designed > that the "providers" need to separately implement every standard > or non-standard combination of algorithm invocations? > > In a properly abstracted design PKCS12KDF would be implemented by > invoking general EVP functions for underlying algorithms, which > would in turn invoke the provider versions of those algorithms. This is exactly the way it works. The implementation of PKCS12KDF fetches the underlying digest algorithm using whatever providers it has available. So, for example, if the PKCS12KDF implementation needs to use SHA256, then it will fetch an available implementation for it - and that implementation may come from the FIPS provider (or any other provider). However, in 3.0, KDFs are themselves fetchable cryptographic algorithms implemented by providers. The FIPS module implements a set of KDFs - but PKCS12KDF is not one of them. Its only available from the default provider. So, the summary is, while you can set things up so that all your crypto, including any digests used by the PKCS12KDF, all come from the FIPS provider, there is no getting away from the fact that you still need to have the default provider loaded in order to have an implementation of the PKCS12KDF itself - which will obviously be outside the module boundary. There aren't any current plans to bring the implementation of PKCS12KDF inside the FIPS module. I don't know whether that is feasible or not. Matt
Re: PKCS12 APIs with fips 3.0
On 2021-01-25 17:53, Zeke Evans wrote: Hi, Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse, PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips provider. It looks like that is because they try to load PKCS12KDF which is not implemented in the fips provider. These were all working in 1.0.2 with the fips 2.0 module. Will they be supported in 3.0 with fips? If not, is there a way for applications running in fips approved mode to support the same functionality and use existing stores/files that contain PKCS12 objects? This is an even larger issue: Is OpenSSL 3.x so badly designed that the "providers" need to separately implement every standard or non-standard combination of algorithm invocations? In a properly abstracted design PKCS12KDF would be implemented by invoking general EVP functions for underlying algorithms, which would in turn invoke the provider versions of those algorithms. The only exception would be if FIPS allowed implementing PKCS12KDF using an otherwise unapproved algorithm such as SHA1. In that particular case, it would make sense to check if a provider offered such as PKCS12KDF variant before trying (and failing) to run provider-independent code that invokes the provider implementation of a FIPS-unapproved algorithm. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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
Re: UI_METHOD functions not being invoked for smart card
On 26/01/21 05:28, George wrote:
Hi,
I'm trying to get OpenSSL 1.0.2u with the FIPS Object Module
2.0.16 in Windows 10 to prompt the user for a smart card's PIN number
every time the application is launched. However, I cannot seem to get
it to work. My UI_METHOD callback functions are not being invoked.
I'm using the following code as a reference:
https://github.com/jjkeijser/ppp/blob/eap-tls/pppd/eap-tls.c
I tried the following:
UI_METHOD* transfer_pin = UI_create_method("transfer_pin");
int writer (UI *ui, UI_STRING *uis)
{
PW_CB_DATA* cb_data = (PW_CB_DATA*)UI_get0_user_data(ui);
UI_set_result(ui, uis, cb_data->password);
return 1;
};
int stub (UI* ui) {return 1;};
int stub_reader (UI *ui, UI_STRING *uis) {return 1;};
UI_method_set_writer(transfer_pin, writer);
UI_method_set_opener(transfer_pin, stub);
UI_method_set_closer(transfer_pin, stub);
UI_method_set_flusher(transfer_pin, stub);
UI_method_set_reader(transfer_pin, stub_reader);
pkey = ENGINE_load_private_key(pkey_engine, pkey_identifier,
transfer_pin, &cb_data);
However, none of the callback functions "writer", "stub", or
"stub_reader" actually get called. Do I need to do anything else to
enable this functionality? I would like to force the user to enter
PIN number every time.
this depends on how openssl for windows was built ; some non-UNIX builds
set the flag OPENSSL_NO_UI_CONSOLE (or possibly OPENSSL_NO_UI) in which
case all UI_methods are effectively disabled. If this flag is set for
your build then you will have to rebuild OpenSSL.
Apart from that, that code snippet above is not the cleanest code I have
ever written - some C/C++ compilers do not like functions defined
insides an "if { } " block; you might have to take the function "int
writer { } " outside of the "if { } " block.
HTH,
JJK
Re: OPenssl 3.0 issues
That should be fixed, I merged a fixup commit yesterday. Cheers, Richard On Mon, 25 Jan 2021 15:56:28 +0100, The Doctor wrote: > > Anyone using BSD running into basename issues? > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici > doctor@@nl2k.ab.ca > Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist > rising! > Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b > > Born 29 Jan 1969 Redhill, Surrey, UK > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Javax.Crypto.AEADBadTagException: Tag Mismatch
Hi, We've Java on the client side & OpenSSL on the server side. After updating Java to 1.8u261 & started getting following exception: Javax.Crypto.AEADBadTagException: Tag Mismatch when trying to communicate with a server having OpenSSL 1.0.2. Looks like the issue is due to AES-GCM ciphers. So, just wanted to know if we need to make some changes in OpenSSL configuration to avoid the given exception. Regards, PR
