IdP 3.3.1 - mac check in GCM failed

[George Stoynev]

Thank you Scott!

Interesting ... I found the following entries in the idp-process.log 
which may be related:

     INFO 
[net.shibboleth.utilities.java.support.security.BasicKeystoreKeyStrategy:289] 
- Key 'secret33' not found
     INFO 
[net.shibboleth.utilities.java.support.security.DataSealer:218] - Data 
was wrapped with a key (secret33) no longer available

The "secret33" string changes randomly.

The secret key has been updated on daily basis and pushed from the first 
server to the second one (two servers in total). Just compared the 
md5sums on both nodes - they match. Rerun the cron job manually and 
copied the files over manually as well - no errors, still md5sums match. 
The error messages persist.

Unfortunately I wasn't able to get this behavior in my QA/Staging 
environment. Both configs are the same though, differences are in 
hostnames and amount of traffic.

Thank you,

George

On 2017-06-12 04:39 PM, users-request at shibboleth.net wrote:
>     2. IdP 3.3.1 - mac check in GCM failed (George Stoynev)
>     3. Re: IdP 3.3.1 - mac check in GCM failed (Cantor, Scott)
>
>
> ----------------------------------------------------------------------
>
> ------------------------------
>
> Message: 2
> Date: Mon, 12 Jun 2017 16:33:42 -0400
> From: George Stoynev <george.stoynev at mcgill.ca>
> To: users at shibboleth.net
> Subject: IdP 3.3.1 - mac check in GCM failed
> Message-ID: <da336828-012b-8377-3f7f-fa5106bde860 at mcgill.ca>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello,
>
> just installed Shibboleth IdP 3.3.1 on RHEL7, Java 8 on our Production
> environment. The following errors are being recorded in the idp-warn.log:
>
> 2017-06-12 10:12:26,902 - ERROR
> [net.shibboleth.utilities.java.support.security.DataSealer:214] -
> Exception unwrapping data
> org.bouncycastle.crypto.InvalidCipherTextException: mac check in GCM failed
>           at org.bouncycastle.crypto.modes.GCMBlockCipher.doFinal(Unknown
> Source)
> 2017-06-12 10:12:26,904 - ERROR
> [org.opensaml.storage.impl.client.ClientStorageService:425] -
> StorageService shibboleth.ClientSessionStorageService: Exception
> unwrapping secured data
> net.shibboleth.utilities.java.support.security.DataSealerException:
> Exception unwrapping data
>           at
> net.shibboleth.utilities.java.support.security.DataSealer.unwrap(DataSealer.java:215)
> Caused by: org.bouncycastle.crypto.InvalidCipherTextException: mac check
> in GCM failed
>           at org.bouncycastle.crypto.modes.GCMBlockCipher.doFinal(Unknown
> Source)
>
> This is similar to an older message here -
> http://shibboleth.1660669.n2.nabble.com/mac-check-in-GCM-failed-td7620157.html.
>
>
> So far, all services seem OK and nobody complains. I was just wondering
> what the source of this error might be and how to mitigate it if possible.
>
> Thank you,
>

Message: 3 Date: Mon, 12 Jun 2017 20:39:06 +0000 From: "Cantor, Scott" 
<cantor.2 at osu.edu> To: Shib Users <users at shibboleth.net> Subject: Re: 
IdP 3.3.1 - mac check in GCM failed Message-ID: 
<49BB1D21-DC84-4A6F-8730-4D980C922385 at osu.edu> Content-Type: text/plain; 
charset="utf-8" On 6/12/17, 4:33 PM, "users on behalf of George Stoynev" 
<users-bounces at shibboleth.net on behalf of george.stoynev at mcgill.ca> wrote:

> So far, all services seem OK and nobody complains. I was just wondering
> what the source of this error might be and how to mitigate it if possible.

Well, they're being forced to login again, possibly over and over if they're switching nodes because the sessions are flipping between keys. The secret key is out of sync on the node(s). It's finding a matching key number/version in the secret key file, but it's the wrong key.

If you're rolling the key daily, just recopy it from whatever source server is generating it. If not, you need to pick one and copy that node's files over to the other nodes to get it back in sync.

-- Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170613/b86d98d2/attachment-0001.html>