Imap ошибка протокола tls неверная запись mac decryptmissingdatabytes

 

Юрий Иванов

Новичок

Сообщений: 3
Баллов: 2
Rating:

0
Authority:

0
Регистрация: 05.04.2021

При получении почты пишет ошибку: Ошибка протокола TLS: Неверная запись MAC DecryptMissingDataBytes. Подскажите, что делать? Версия Bat 6.0.12
 

George Salnik

Администратор

Сообщений: 1606
Баллов: 2905
Rating:

117
Authority:

116
Регистрация: 21.11.2013

TheBat 6 не хочет работать с gmail, об этом вопрос?
 

Юрий Иванов

Новичок

Сообщений: 3
Баллов: 2
Rating:

0
Authority:

0
Регистрация: 05.04.2021

#3


0
 

Цитата
George Salnik написал:
TheBat 6 не хочет работать с gmail, об этом вопрос?

Это Яндекс почта
 

George Salnik

Администратор

Сообщений: 1606
Баллов: 2905
Rating:

117
Authority:

116
Регистрация: 21.11.2013

Что ж. Стоит надеяться, что сюда заглянет кто с 6-м мышонком и яндексом, чтобы показать Вам свои настройки. Техподдержка Вам не подскажет, скорее всего, т.к. версия неактуальная.
 

Юрий Иванов

Новичок

Сообщений: 3
Баллов: 2
Rating:

0
Authority:

0
Регистрация: 05.04.2021

#5


0
 

Цитата
George Salnik написал:
Что ж. Стоит надеяться, что сюда заглянет кто с 6-м мышонком и яндексом, чтобы показать Вам свои настройки. Техподдержка Вам не подскажет, скорее всего, т.к. версия неактуальная.

Причем началось неделю назад ни с того ни с сего, до этого работало несколько лет, а сейчас  то работает, то выводит эту ошибку.
Источник

Здравствуйте. 
Ежедневная проблема с Kaspersky Security Center установленным на Windows Server 2012r2.

 
Каждое утро заходя на сервер вижу сообщение:
«Не удалось подключиться к Серверу администрирования «localhost». Укажите другой адрес или попытайтесь подключиться еще раз.»

 
При этом в отчете «События аудита» появляется сообщение:

 
Имя события Сервер остановлен
Важность: Информационное сообщение
Программа: Сервер администрирования Kaspersky Security Center
Номер версии: 10.1.249
Название задачи:
Компьютер: Сервер администрирования <имя>
Группа: <имя>
Время: 26 декабря 2014 г. 2:00:02
Имя виртуального Cервера:
Описание: Остановлена служба Сервера администрирования

 
При перезапуске приложения вручную все работает нормально до следующего утра. Подскажите, что делать?

Источник

Hi,

Testing Kowl but I get this error tls: bad record MAC
Full output:

kowl_1  | {"level":"info","msg":"config filepath is not set, proceeding with options set from env variables and flags"}
kowl_1  | {"level":"info","ts":"2022-03-29T12:55:23.258Z","msg":"started Kowl","version":"master","git_sha":"c6a6f4cb15d9e58e28b13930af95b272e2eae2ca","built":"2022-02-27T09:45:11Z"}
kowl_1  | {"level":"info","ts":"2022-03-29T12:55:23.266Z","msg":"connecting to Kafka seed brokers, trying to fetch cluster metadata"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.266Z","msg":"opening connection to broker","source":"kafka_client","addr":"kafka-app-test.mydomain.net:9193","broker":"seed 0"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"kafka connection succeeded","source":"kafka_client_hooks","host":"kafka-app-test.mydomain.net","dial_duration":0.0478782}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"connection opened to broker","source":"kafka_client","addr":"kafka-app-test.mydomain.net:9193","broker":"seed 0"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"issuing api versions request","source":"kafka_client","broker":"seed 0","version":3}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"wrote ApiVersions v3","source":"kafka_client","broker":"seed 0","bytes_written":61,"write_wait":0.0000375,"time_to_write":0.0000462,"err":null}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.347Z","msg":"read ApiVersions v3","source":"kafka_client","broker":"seed 0","bytes_read":0,"read_wait":0.0000645,"time_to_read":0.032389,"err":"local error: tls: bad record MAC"}
kowl_1  | {"level":"error","ts":"2022-03-29T12:55:23.347Z","msg":"unable to request api versions","source":"kafka_client","broker":"seed 0","err":"local error: tls: bad record MAC"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.347Z","msg":"connection initialization failed","source":"kafka_client","addr":"kafka-app-test.mydomain.net:9193","broker":"seed 0","err":"local error: tls: bad record MAC"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.347Z","msg":"kafka broker disconnected","source":"kafka_client_hooks","host":"kafka-app-test.mydomain.net"}
kowl_1  | {"level":"fatal","ts":"2022-03-29T12:55:23.347Z","msg":"failed to create kafka service","error":"failed to test kafka connection: failed to request metadata: local error: tls: bad record MAC"}

Using this docker-compose.yaml

version: '2'

services:

  kowl:
    image: 'quay.io/cloudhut/kowl:master'
    ports:
      - '8088:8080'
    environment:
      - KAFKA_BROKERS=kafka-app-test.mydomain.net:9193
      - KAFKA_TLS_ENABLED=true
      - KAFKA_TLS_CAFILEPATH=/vdsp_test_ca.cer
      - KAFKA_TLS_KEYFILEPATH=/cert.p12
      - KAFKA_TLS_PASSPHRASE=4IfS**************6dxGj
      - KAFKA_TLS_INSECURESKIPTLSVERIFY=true
      - LOGGER_LEVEL=debug
    volumes:
      - '/c/Users/myuserid/projects/kowl/certs/vdsp_test_ca.cer:/vdsp_test_ca.cer'
      - '/c/Users/myuserid/projects/kowl/certs/cert.p12:/cert.p12'

Any idea why this happens?

Hi,

Testing Kowl but I get this error tls: bad record MAC
Full output:

kowl_1  | {"level":"info","msg":"config filepath is not set, proceeding with options set from env variables and flags"}
kowl_1  | {"level":"info","ts":"2022-03-29T12:55:23.258Z","msg":"started Kowl","version":"master","git_sha":"c6a6f4cb15d9e58e28b13930af95b272e2eae2ca","built":"2022-02-27T09:45:11Z"}
kowl_1  | {"level":"info","ts":"2022-03-29T12:55:23.266Z","msg":"connecting to Kafka seed brokers, trying to fetch cluster metadata"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.266Z","msg":"opening connection to broker","source":"kafka_client","addr":"kafka-app-test.mydomain.net:9193","broker":"seed 0"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"kafka connection succeeded","source":"kafka_client_hooks","host":"kafka-app-test.mydomain.net","dial_duration":0.0478782}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"connection opened to broker","source":"kafka_client","addr":"kafka-app-test.mydomain.net:9193","broker":"seed 0"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"issuing api versions request","source":"kafka_client","broker":"seed 0","version":3}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"wrote ApiVersions v3","source":"kafka_client","broker":"seed 0","bytes_written":61,"write_wait":0.0000375,"time_to_write":0.0000462,"err":null}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.347Z","msg":"read ApiVersions v3","source":"kafka_client","broker":"seed 0","bytes_read":0,"read_wait":0.0000645,"time_to_read":0.032389,"err":"local error: tls: bad record MAC"}
kowl_1  | {"level":"error","ts":"2022-03-29T12:55:23.347Z","msg":"unable to request api versions","source":"kafka_client","broker":"seed 0","err":"local error: tls: bad record MAC"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.347Z","msg":"connection initialization failed","source":"kafka_client","addr":"kafka-app-test.mydomain.net:9193","broker":"seed 0","err":"local error: tls: bad record MAC"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.347Z","msg":"kafka broker disconnected","source":"kafka_client_hooks","host":"kafka-app-test.mydomain.net"}
kowl_1  | {"level":"fatal","ts":"2022-03-29T12:55:23.347Z","msg":"failed to create kafka service","error":"failed to test kafka connection: failed to request metadata: local error: tls: bad record MAC"}

Using this docker-compose.yaml

version: '2'

services:

  kowl:
    image: 'quay.io/cloudhut/kowl:master'
    ports:
      - '8088:8080'
    environment:
      - KAFKA_BROKERS=kafka-app-test.mydomain.net:9193
      - KAFKA_TLS_ENABLED=true
      - KAFKA_TLS_CAFILEPATH=/vdsp_test_ca.cer
      - KAFKA_TLS_KEYFILEPATH=/cert.p12
      - KAFKA_TLS_PASSPHRASE=4IfS**************6dxGj
      - KAFKA_TLS_INSECURESKIPTLSVERIFY=true
      - LOGGER_LEVEL=debug
    volumes:
      - '/c/Users/myuserid/projects/kowl/certs/vdsp_test_ca.cer:/vdsp_test_ca.cer'
      - '/c/Users/myuserid/projects/kowl/certs/cert.p12:/cert.p12'

Any idea why this happens?

 INFO: [Oct 15 10:51:47.144] creating new server object from API response server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.144] creating new server object from API response server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.145] registering event listeners: console, state, resources... server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.146] registering event listeners: console, state, resources... server=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.147] syncing stop configuration with configured docker environment server=46c11588-8b63-4c03-82f9-54d157b34476
DEBUG: [Oct 15 10:51:47.148] syncing stop configuration with configured docker environment server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.149] finished processing server configurations duration=5.705226ms
 INFO: [Oct 15 10:51:47.158] loaded configuration for server server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.158] loaded configuration for server server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.160] configuring server environment and restoring to previous state server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.160] configuring server environment and restoring to previous state server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.166] detected server is running, re-attaching to process... server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.166] detected server is running, re-attaching to process... server=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.187] saw server status change event server=852ac61e-8029-4587-959e-450971edeecd status=running
DEBUG: [Oct 15 10:51:47.192] starting resource polling for container container_id=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.210] saw server status change event server=46c11588-8b63-4c03-82f9-54d157b34476 status=running
 INFO: [Oct 15 10:51:47.215] configuring internal webserver host_address=0.0.0.0 host_port=8080 use_auto_tls=false use_ssl=true
DEBUG: [Oct 15 10:51:47.215] starting resource polling for container container_id=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.216] sftp subsystem listening for connections host=0.0.0.0 port=2022
2020/10/15 10:51:52 http: TLS handshake error from xxx.xxx.xxx.58:54592: local error: tls: bad record MAC
2020/10/15 10:51:52 http: TLS handshake error from xxx.xxx.xxx.58:54594: local error: tls: bad record MAC

I’ve confirmed there’s not any faulty hardware or drivers through extensive testing inside and outside the OS. Turned off hardware preload to be sure with no repair. There’s no security issue. And the MTU is fine. I reported it since it’s a Go specific error and doesn’t provide enough information

 INFO: [Oct 15 10:51:47.144] creating new server object from API response server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.144] creating new server object from API response server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.145] registering event listeners: console, state, resources... server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.146] registering event listeners: console, state, resources... server=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.147] syncing stop configuration with configured docker environment server=46c11588-8b63-4c03-82f9-54d157b34476
DEBUG: [Oct 15 10:51:47.148] syncing stop configuration with configured docker environment server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.149] finished processing server configurations duration=5.705226ms
 INFO: [Oct 15 10:51:47.158] loaded configuration for server server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.158] loaded configuration for server server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.160] configuring server environment and restoring to previous state server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.160] configuring server environment and restoring to previous state server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.166] detected server is running, re-attaching to process... server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.166] detected server is running, re-attaching to process... server=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.187] saw server status change event server=852ac61e-8029-4587-959e-450971edeecd status=running
DEBUG: [Oct 15 10:51:47.192] starting resource polling for container container_id=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.210] saw server status change event server=46c11588-8b63-4c03-82f9-54d157b34476 status=running
 INFO: [Oct 15 10:51:47.215] configuring internal webserver host_address=0.0.0.0 host_port=8080 use_auto_tls=false use_ssl=true
DEBUG: [Oct 15 10:51:47.215] starting resource polling for container container_id=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.216] sftp subsystem listening for connections host=0.0.0.0 port=2022
2020/10/15 10:51:52 http: TLS handshake error from xxx.xxx.xxx.58:54592: local error: tls: bad record MAC
2020/10/15 10:51:52 http: TLS handshake error from xxx.xxx.xxx.58:54594: local error: tls: bad record MAC

I’ve confirmed there’s not any faulty hardware or drivers through extensive testing inside and outside the OS. Turned off hardware preload to be sure with no repair. There’s no security issue. And the MTU is fine. I reported it since it’s a Go specific error and doesn’t provide enough information

We met an issue about openldap + openssl.

when a multithread client(30 threads) did connect to OPENLDAP server, the server side has «Bad Record MAC» error at TLS handshake randomly.

env
openldap+openssl TLS
RHEL7.5 openssl 1.0.2k
openldap2.4.43

TLS configure
The TLS configures are: TLS1.2 ,  ssf=128 and Cipher_Suite="AES:!NULL:!EXPORT" 

Error connection
Error connection progress are
client->server: Client Hello
server->client:Server Hello, Certificate, Server Hello Done
client->server: Client key Exchange
client->server: change cipher spec
client->server: Encryted Handshake Message
Server->client: Alert(Level: Fatal, Decription: Bad Record MAC)env
openldap+openssl TLS
RHEL7.5 openssl 1.0.2k
openldap2.4.43

when
when a multithread client(30 threads) connects OPENLDAP server, server side has «Bad Record MAC» error at TLS handshake
.
how frequence
This issue occurs randomly, for part connections.

TLS configure
The TLS configures are: TLS1.2 ,  ssf=128 and    Cipher_Suite="AES:!NULL:!EXPORT" 

Error connection
Error connection progress are
client->server: Client Hello
server->client:Server Hello, Certificate, Server Hello Done
client->server: Client key Exchange
client->server: change cipher spec
client->server: Encryted Handshake Message
Server->client: Alert(Level: Fatal, Decription: Bad Record MAC)

Источник

Добрый день! Срочная проблема — вчера обновили Exchange до последней версии (последовательно установили SP1 и затем CU9) — после чего перестала работать авторизация по IMAP. Настройки такие:

порт IMAP — 143 (TLS)

порт SMTP — 587 (TLS)

авторизация SMTP включена. Но при этом после установки перечисленных обновлений пароль при входе по IMAP не принимается. OWA работает нормально, то есть сами пароли в норме. Что предпринять?

Вот как выглядит команда Get-IMAPSettings на данный момент:

И вот такое в логах вижу:

2015-07-19T07:54:38.592Z,0000000000000006,4,192.168.1.6:143,90.155.179.103:27144,,4,44,333,authenticate,NTLM,»R=»»6e2l NO AUTHENTICATE failed.»»;Msg=»»AuthFailed:LogonDenied,User: not found»»;ErrMsg=AuthFailed:LogonDenied»
2015-07-19T07:54:38.638Z,0000000000000006,5,192.168.1.6:143,90.155.179.103:27144,info@luxury.local,28,36,23,login,info@luxury.local *****,»R=»»dw72 NO LOGIN failed.»»;Msg=LogonFailed:LogonDenied;ErrMsg=LogonFailed:LogonDenied»

Но именно этот логин проходит авторизацию через owa, проблема только с IMAP почему-то. Что делать? Целый офис вынужден временно пользоваться owa из-за этого бага.

  • Изменено

    19 июля 2015 г. 7:58

Источник

 

Юрий Иванов

Новичок

Сообщений: 3
Баллов: 2
Rating:

0
Authority:

0
Регистрация: 05.04.2021

При получении почты пишет ошибку: Ошибка протокола TLS: Неверная запись MAC DecryptMissingDataBytes. Подскажите, что делать? Версия Bat 6.0.12
 

George Salnik

Администратор

Сообщений: 1523
Баллов: 2756
Rating:

89
Authority:

89
Регистрация: 21.11.2013

TheBat 6 не хочет работать с gmail, об этом вопрос?
 

Юрий Иванов

Новичок

Сообщений: 3
Баллов: 2
Rating:

0
Authority:

0
Регистрация: 05.04.2021

#3


0

05.04.2021 14:59:01

Цитата
George Salnik написал:
TheBat 6 не хочет работать с gmail, об этом вопрос?

Это Яндекс почта
 

George Salnik

Администратор

Сообщений: 1523
Баллов: 2756
Rating:

89
Authority:

89
Регистрация: 21.11.2013

Что ж. Стоит надеяться, что сюда заглянет кто с 6-м мышонком и яндексом, чтобы показать Вам свои настройки. Техподдержка Вам не подскажет, скорее всего, т.к. версия неактуальная.
 

Юрий Иванов

Новичок

Сообщений: 3
Баллов: 2
Rating:

0
Authority:

0
Регистрация: 05.04.2021

#5


0

06.04.2021 09:20:26

Цитата
George Salnik написал:
Что ж. Стоит надеяться, что сюда заглянет кто с 6-м мышонком и яндексом, чтобы показать Вам свои настройки. Техподдержка Вам не подскажет, скорее всего, т.к. версия неактуальная.

Причем началось неделю назад ни с того ни с сего, до этого работало несколько лет, а сейчас  то работает, то выводит эту ошибку.

Hi,

Testing Kowl but I get this error tls: bad record MAC
Full output:

kowl_1  | {"level":"info","msg":"config filepath is not set, proceeding with options set from env variables and flags"}
kowl_1  | {"level":"info","ts":"2022-03-29T12:55:23.258Z","msg":"started Kowl","version":"master","git_sha":"c6a6f4cb15d9e58e28b13930af95b272e2eae2ca","built":"2022-02-27T09:45:11Z"}
kowl_1  | {"level":"info","ts":"2022-03-29T12:55:23.266Z","msg":"connecting to Kafka seed brokers, trying to fetch cluster metadata"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.266Z","msg":"opening connection to broker","source":"kafka_client","addr":"kafka-app-test.mydomain.net:9193","broker":"seed 0"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"kafka connection succeeded","source":"kafka_client_hooks","host":"kafka-app-test.mydomain.net","dial_duration":0.0478782}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"connection opened to broker","source":"kafka_client","addr":"kafka-app-test.mydomain.net:9193","broker":"seed 0"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"issuing api versions request","source":"kafka_client","broker":"seed 0","version":3}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"wrote ApiVersions v3","source":"kafka_client","broker":"seed 0","bytes_written":61,"write_wait":0.0000375,"time_to_write":0.0000462,"err":null}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.347Z","msg":"read ApiVersions v3","source":"kafka_client","broker":"seed 0","bytes_read":0,"read_wait":0.0000645,"time_to_read":0.032389,"err":"local error: tls: bad record MAC"}
kowl_1  | {"level":"error","ts":"2022-03-29T12:55:23.347Z","msg":"unable to request api versions","source":"kafka_client","broker":"seed 0","err":"local error: tls: bad record MAC"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.347Z","msg":"connection initialization failed","source":"kafka_client","addr":"kafka-app-test.mydomain.net:9193","broker":"seed 0","err":"local error: tls: bad record MAC"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.347Z","msg":"kafka broker disconnected","source":"kafka_client_hooks","host":"kafka-app-test.mydomain.net"}
kowl_1  | {"level":"fatal","ts":"2022-03-29T12:55:23.347Z","msg":"failed to create kafka service","error":"failed to test kafka connection: failed to request metadata: local error: tls: bad record MAC"}

Using this docker-compose.yaml

version: '2'

services:

  kowl:
    image: 'quay.io/cloudhut/kowl:master'
    ports:
      - '8088:8080'
    environment:
      - KAFKA_BROKERS=kafka-app-test.mydomain.net:9193
      - KAFKA_TLS_ENABLED=true
      - KAFKA_TLS_CAFILEPATH=/vdsp_test_ca.cer
      - KAFKA_TLS_KEYFILEPATH=/cert.p12
      - KAFKA_TLS_PASSPHRASE=4IfS**************6dxGj
      - KAFKA_TLS_INSECURESKIPTLSVERIFY=true
      - LOGGER_LEVEL=debug
    volumes:
      - '/c/Users/myuserid/projects/kowl/certs/vdsp_test_ca.cer:/vdsp_test_ca.cer'
      - '/c/Users/myuserid/projects/kowl/certs/cert.p12:/cert.p12'

Any idea why this happens?

Hi,

Testing Kowl but I get this error tls: bad record MAC
Full output:

kowl_1  | {"level":"info","msg":"config filepath is not set, proceeding with options set from env variables and flags"}
kowl_1  | {"level":"info","ts":"2022-03-29T12:55:23.258Z","msg":"started Kowl","version":"master","git_sha":"c6a6f4cb15d9e58e28b13930af95b272e2eae2ca","built":"2022-02-27T09:45:11Z"}
kowl_1  | {"level":"info","ts":"2022-03-29T12:55:23.266Z","msg":"connecting to Kafka seed brokers, trying to fetch cluster metadata"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.266Z","msg":"opening connection to broker","source":"kafka_client","addr":"kafka-app-test.mydomain.net:9193","broker":"seed 0"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"kafka connection succeeded","source":"kafka_client_hooks","host":"kafka-app-test.mydomain.net","dial_duration":0.0478782}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"connection opened to broker","source":"kafka_client","addr":"kafka-app-test.mydomain.net:9193","broker":"seed 0"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"issuing api versions request","source":"kafka_client","broker":"seed 0","version":3}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.314Z","msg":"wrote ApiVersions v3","source":"kafka_client","broker":"seed 0","bytes_written":61,"write_wait":0.0000375,"time_to_write":0.0000462,"err":null}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.347Z","msg":"read ApiVersions v3","source":"kafka_client","broker":"seed 0","bytes_read":0,"read_wait":0.0000645,"time_to_read":0.032389,"err":"local error: tls: bad record MAC"}
kowl_1  | {"level":"error","ts":"2022-03-29T12:55:23.347Z","msg":"unable to request api versions","source":"kafka_client","broker":"seed 0","err":"local error: tls: bad record MAC"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.347Z","msg":"connection initialization failed","source":"kafka_client","addr":"kafka-app-test.mydomain.net:9193","broker":"seed 0","err":"local error: tls: bad record MAC"}
kowl_1  | {"level":"debug","ts":"2022-03-29T12:55:23.347Z","msg":"kafka broker disconnected","source":"kafka_client_hooks","host":"kafka-app-test.mydomain.net"}
kowl_1  | {"level":"fatal","ts":"2022-03-29T12:55:23.347Z","msg":"failed to create kafka service","error":"failed to test kafka connection: failed to request metadata: local error: tls: bad record MAC"}

Using this docker-compose.yaml

version: '2'

services:

  kowl:
    image: 'quay.io/cloudhut/kowl:master'
    ports:
      - '8088:8080'
    environment:
      - KAFKA_BROKERS=kafka-app-test.mydomain.net:9193
      - KAFKA_TLS_ENABLED=true
      - KAFKA_TLS_CAFILEPATH=/vdsp_test_ca.cer
      - KAFKA_TLS_KEYFILEPATH=/cert.p12
      - KAFKA_TLS_PASSPHRASE=4IfS**************6dxGj
      - KAFKA_TLS_INSECURESKIPTLSVERIFY=true
      - LOGGER_LEVEL=debug
    volumes:
      - '/c/Users/myuserid/projects/kowl/certs/vdsp_test_ca.cer:/vdsp_test_ca.cer'
      - '/c/Users/myuserid/projects/kowl/certs/cert.p12:/cert.p12'

Any idea why this happens?

 INFO: [Oct 15 10:51:47.144] creating new server object from API response server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.144] creating new server object from API response server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.145] registering event listeners: console, state, resources... server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.146] registering event listeners: console, state, resources... server=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.147] syncing stop configuration with configured docker environment server=46c11588-8b63-4c03-82f9-54d157b34476
DEBUG: [Oct 15 10:51:47.148] syncing stop configuration with configured docker environment server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.149] finished processing server configurations duration=5.705226ms
 INFO: [Oct 15 10:51:47.158] loaded configuration for server server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.158] loaded configuration for server server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.160] configuring server environment and restoring to previous state server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.160] configuring server environment and restoring to previous state server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.166] detected server is running, re-attaching to process... server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.166] detected server is running, re-attaching to process... server=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.187] saw server status change event server=852ac61e-8029-4587-959e-450971edeecd status=running
DEBUG: [Oct 15 10:51:47.192] starting resource polling for container container_id=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.210] saw server status change event server=46c11588-8b63-4c03-82f9-54d157b34476 status=running
 INFO: [Oct 15 10:51:47.215] configuring internal webserver host_address=0.0.0.0 host_port=8080 use_auto_tls=false use_ssl=true
DEBUG: [Oct 15 10:51:47.215] starting resource polling for container container_id=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.216] sftp subsystem listening for connections host=0.0.0.0 port=2022
2020/10/15 10:51:52 http: TLS handshake error from xxx.xxx.xxx.58:54592: local error: tls: bad record MAC
2020/10/15 10:51:52 http: TLS handshake error from xxx.xxx.xxx.58:54594: local error: tls: bad record MAC

I’ve confirmed there’s not any faulty hardware or drivers through extensive testing inside and outside the OS. Turned off hardware preload to be sure with no repair. There’s no security issue. And the MTU is fine. I reported it since it’s a Go specific error and doesn’t provide enough information

 INFO: [Oct 15 10:51:47.144] creating new server object from API response server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.144] creating new server object from API response server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.145] registering event listeners: console, state, resources... server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.146] registering event listeners: console, state, resources... server=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.147] syncing stop configuration with configured docker environment server=46c11588-8b63-4c03-82f9-54d157b34476
DEBUG: [Oct 15 10:51:47.148] syncing stop configuration with configured docker environment server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.149] finished processing server configurations duration=5.705226ms
 INFO: [Oct 15 10:51:47.158] loaded configuration for server server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.158] loaded configuration for server server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.160] configuring server environment and restoring to previous state server=852ac61e-8029-4587-959e-450971edeecd
 INFO: [Oct 15 10:51:47.160] configuring server environment and restoring to previous state server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.166] detected server is running, re-attaching to process... server=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.166] detected server is running, re-attaching to process... server=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.187] saw server status change event server=852ac61e-8029-4587-959e-450971edeecd status=running
DEBUG: [Oct 15 10:51:47.192] starting resource polling for container container_id=852ac61e-8029-4587-959e-450971edeecd
DEBUG: [Oct 15 10:51:47.210] saw server status change event server=46c11588-8b63-4c03-82f9-54d157b34476 status=running
 INFO: [Oct 15 10:51:47.215] configuring internal webserver host_address=0.0.0.0 host_port=8080 use_auto_tls=false use_ssl=true
DEBUG: [Oct 15 10:51:47.215] starting resource polling for container container_id=46c11588-8b63-4c03-82f9-54d157b34476
 INFO: [Oct 15 10:51:47.216] sftp subsystem listening for connections host=0.0.0.0 port=2022
2020/10/15 10:51:52 http: TLS handshake error from xxx.xxx.xxx.58:54592: local error: tls: bad record MAC
2020/10/15 10:51:52 http: TLS handshake error from xxx.xxx.xxx.58:54594: local error: tls: bad record MAC

I’ve confirmed there’s not any faulty hardware or drivers through extensive testing inside and outside the OS. Turned off hardware preload to be sure with no repair. There’s no security issue. And the MTU is fine. I reported it since it’s a Go specific error and doesn’t provide enough information

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account


Closed

jceloria opened this issue

Jul 2, 2020

· 11 comments


Closed

local error: tls: bad record MAC

#2838

jceloria opened this issue

Jul 2, 2020

· 11 comments

Comments

@jceloria

Summary

This is a new install using docker-compose, following the getting started guide. After running docker-compose up, I proceed to the console and see Token exchange refused. I came across #2353, #1818, #2511, and #2521 all of which led me to try different options to resolve this issue, unfortunately nothing has worked for me thus far.
…

Steps to Reproduce

  1. Configure docker-compose.yml and ttn-lw-stack.yml
  2. Initialize the database, create admin user, create oauth-client using the same value as client-secret as outlined in the getting-started documentation for console.oauth.client-secret
  3. run: docker-compose up

What do you see now?

I’m able to resolve the host name from the container:

/ # ping -q -c1 lora.<redacted>
PING lora.<redacted> (192.168.1.10): 56 data bytes

--- lora.<redacted> ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.052/0.052/0.052 ms

I have verified the certificates:

/ # ttn-lw-stack config | grep .pem | sed 's/^ *//g'
--tls.certificate="/run/secrets/cert.pem"
--tls.key="/run/secrets/key.pem"
--tls.root-ca="/run/secrets/ca.pem"

/ # apk add openssl
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
(1/1) Installing openssl (1.1.1g-r0)
Executing busybox-1.30.1-r3.trigger
OK: 8 MiB in 19 packages

/ # openssl x509 -in /run/secrets/ca.pem -text -noout | awk '/Subject Key Identifier/ && $0 != "" {getline; print $0}' | tr -d ' '
A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1

/ # openssl x509 -in /run/secrets/cert.pem -text -noout | awk '/Authority Key Identifier/ && $0 != "" {getline; print $0}' | tr -d ' '
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1

When I run curl against localhost and the host name I’m using in the config I get the following:

/ # for host in localhost lora.<redacted>; do echo ${host}:; curl https://${host}:8885; echo -e '-----n'; done
localhost:
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
-----

lora.<redacted>:
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
-----

I get the same outcome when I specify the ca cert:
curl --cacert /run/secrets/ca.pem https://${host}:8885

When viewing the docker logs, I see the following when attempting to connect:

2020/07/02 18:05:42 http: TLS handshake error from 127.0.0.1:47152: local error: tls: bad record MAC
2020/07/02 18:05:42 http: TLS handshake error from 192.168.176.1:36420: local error: tls: bad record MAC

Am I missing something?

What do you want to see instead?

I would like to login to the console.

Environment

#─► rpm -q centos-release docker-ce
centos-release-8.1-1.1911.0.9.el8.x86_64
docker-ce-19.03.10-3.el7.x86_64

/ # ttn-lw-stack version
The Things Stack for LoRaWAN: ttn-lw-stack
Version:             3.8.4
Build date:          2020-06-12T17:15:05Z
Git commit:          d63f7de74
Go version:          go1.14.4
OS/Arch:             linux/amd64

How do you propose to implement this?

no idea.

How do you propose to test this?

n/a

Can you do this yourself and submit a Pull Request?

n/a

@KrishnaIyer

  1. How did you generate the SSL Certs? If you’ve deployed this on a public machine, you can either use the in-built stack ACME or query certificates yourself using Lets Encrypt.
  2. Does the CN (Canonical Name) of the certificate match the host where this is deployed?

If you’re using the stack locally (localhost), then I’d recommend interacting with the stack without TLS (using the http/mqtt/ws/grpc ports).

for host in localhost lora.; do echo ${host}:; curl https://${host}:8885; echo -e ‘——n’; done

This is quite wrong. No Certificate Authority will provide you a certificate for localhost and if you’re using self-signed certs, please don’t use this on a public deployment.

@jceloria

Thank you for the quick response.

1) How did you generate the SSL Certs? If you’ve deployed this on a public
machine, you can either use the in-built stack ACME or query certificates
yourself using Lets Encrypt.
— I’m using an existing Let’s Encrypt generated by acme.sh and managed
outside of The Things Stack for my domain.
2) Does the CN (Canonical Name) of the certificate match the host where
this is deployed?
— Yes, the certificate I use is a wildcard certificate that I use for other
services that are exposed publicly, The Things Stack is not exposed
publicly and I have not yet decided if I will ever do so. If I do decide to
publicly expose it, then it will be behind an SSL terminated reverse Apache
proxy protected with oauth that I maintain. The goal was to test this out
as a POC before doing anything else.

If you’re using the stack locally (localhost), then I’d recommend

interacting with the stack without TLS (using the http/mqtt/ws/grpc ports).
— That was my original intent, but I had received the Token exchange
refused message upon initial login after bringing up the stack and
connecting to http://lora.<redacted>:1885. After searching github and the
forum, I read something about TLS being used on the back end or something (I
can’t quite recall), that led me down the path of verifying that my
certificates were in fact valid. I also noticed that the certificates were
not included when bringing up the stack when configured in the config file,
but instead I needed to supply the values using the environment variables
instead.

for host in localhost lora.; do echo ${host}:; curl https://${host}:8885;

echo -e ‘——n’; done
Something must have gotten stripped from that message because its a for
loop testing curl against localhost and a redacted hostname that I was not
comfortable displaying publicly `lora.»redacted»` the «redacted» part of
that for loop is my domain, which I demonstrated as being a valid hostname
with the ping statement I mentioned in the issue. The only reason I had
included localhost, was some previous comments on other issues had
mentioned attempting the connection to localhost which succeeded. The
attempt was purely a last ditch «what else can I possibly try» effort.

…

On Fri, Jul 3, 2020 at 2:17 PM Krishna Iyer Easwaran < ***@***.***> wrote:

1. How did you generate the SSL Certs? If you’ve deployed this on a
public machine, you can either use the in-built stack ACME or query
certificates yourself using Lets Encrypt.
2. Does the CN (Canonical Name) of the certificate match the host
where this is deployed?

If you’re using the stack locally (localhost), then I’d recommend
interacting with the stack without TLS (using the http/mqtt/ws/grpc ports).

for host in localhost lora.; do echo ${host}:; curl https://${host}:8885;
echo -e ‘——n’; done

This is quite wrong. No Certificate Authority will provide you a
certificate for localhost and if you’re using self-signed certs, please
don’t use this on a public deployment.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2838 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKKWYBP4QHVB76IMZYXZIDRZYVEVANCNFSM4OPE4G6A>
.

@benolayinka

Let me see if understand right

  • You have a machine exposing lora.redacted with Apache using acme certificates for TLS
  • You’re running a docker container on this machine but you’re not exposing The Things Stack with Apache
  • You’re running all of the above commands on this machine, so a ping to localhost will never leave the machine but a ping to lora.redacted should hit a DNS resolver somewhere and then come back to the machine through Apache

If I have that right, is this machine physically local to you? Are you opening a browser on this machine and hitting localhost:1885?

@jceloria

I’m accessing all resources from my local network at the moment, this is
simply a POC.

I have a UniFi Security Gateway with ports 80 and 443 mapped to a docker
host on a private subnet running Apache. The same docker host that’s
running Apache is also running The Things Stack. I’m using split DNS, and I
only have a few services that I’m exposing publicly. I am not yet exposing
lora.redacted either through the Apache reverse proxy nor DNS. All of the
services I’m hosting (both public and private) are using the same Let’s
Encrypt wildcard certificate. I’m using dnsmasq on my USG as the internal
resolver. I have multiple CNAME/aliases pointing to the docker host running
Apache/The Things Stack/etc. Apache is only ever involved when attempting
to connect to public DNS from outside of my local network. The DNS entry,
lora.redacted (192.168.1.10) points directly to the docker host.

To simplify things:

— local network -> http://lora.redacted:1885 (192.168.1.10:1885) -> «Token
exchange refused»
— local network -> ssh tunnel (1885:192.168.1.10:1885) ->
http://localhost:1885 -> «Token exchange refused»
— local network -> https://lora.redacted:8885 (192.168.1.10:1885) -> «Token
exchange refused»
— local network -> ssh tunnel (8885:192.168.1.10:8885
<http://192.168.1.10:1885>) -> https://localhost:8885
<http://localhost:1885> -> «SSL_ERROR_BAD_CERT_DOMAIN» -> «Token
exchange refused»
— local network -> https://www.redacted (192.168.1.10:443) -> OK
— public network -> https://www.redacted -> OK

…

On Mon, Jul 6, 2020 at 9:14 AM Ben Olayinka ***@***.***> wrote:
Let me see if understand right

— You have a machine exposing lora.redacted with Apache using acme
certificates for TLS
— You’re running a docker container on this machine but you’re not
exposing The Things Stack with Apache
— You’re running all of the above commands on this machine, so a ping
to localhost will never leave the machine but a ping to lora.redacted
should hit a DNS resolver somewhere and then come back to the machine
through Apache

If I have that right, is this machine physically local to you? Are you
opening a browser on this machine and hitting localhost:1885?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2838 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKKWYGNIGJGWBKYF5U4NR3R2HL2ZANCNFSM4OPE4G6A>
.

@KrishnaIyer

@jceloria: This has to do with your console/oauth configuration. Can you add that here?

@jceloria

That’s most likely the case, I’m sure.

I posted both the docker-compose.yml and ttn-lw-stack.yml, under Steps to reproduce (1.) as gists, or were you referring to something else?

@KrishnaIyer

Ah yeah indeed. I just saw that. I think I see the issue here.
For your configuration, only https://lora.redacted will work. Also your config is missing :8885 unless you’re proxying https://lora.redacted to https://lora.redacted:8885.

What values did you use as callback when creating the Oauth client?

@jceloria

I used Ansible to deploy with the following arguments to docker-compose which I grabbed from the getting-started/installation page:

      - >-
        pull
      - >-
        run --rm stack is-db init
      - >-
        run --rm stack is-db create-admin-user --id admin --email '{{ admin_email }}'
        --password '{{ admin_password }}'
      - >-
        run --rm stack is-db create-oauth-client --id cli --name 'Command Line Interface'
        --owner admin --no-secret --redirect-uri 'local-callback' --redirect-uri 'code'
      - >-
        run --rm stack is-db create-oauth-client --id console --owner admin
        --secret '{{ client_secret }}' --redirect-uri 'https://{{ fqdn }}/console/oauth/callback'
        --redirect-uri '/console/oauth/callback' --logout-redirect-uri 'https://{{ fqdn }}/console'
        --logout-redirect-uri '/console'

{{ fqdn }}: lora.redacted
{{ client_secret }}: is the same value that’s in ttn-lw-stack.yml

In all likelihood, I’m missing something that’s not obvious to me with the configuration. I appreciate the assistance.

@jceloria

I see what you’re saying, since this is all local, I should be able to update the config to the following:

# Web UI configuration
console:
  ui:
    canonical-url: 'https://{{ fqdn }}:1885/console'
    is:
      base-url: 'https://{{ fqdn }}:1885/api/v3'
    gs:
      base-url: 'https://{{ fqdn }}:1885/api/v3'
    ns:
      base-url: 'https://{{ fqdn }}:1885/api/v3'
    as:
      base-url: 'https://{{ fqdn }}:1885/api/v3'
    js:
      base-url: 'https://{{ fqdn }}:1885/api/v3'
    qrg:
      base-url: 'https://{{ fqdn }}:1885/api/v3'
    edtc:
      base-url: 'https://{{ fqdn }}:1885/api/v3'

  oauth:
    authorize-url: 'https://{{ fqdn }}:1885/oauth/authorize'
    token-url: 'https://{{ fqdn }}:1885/oauth/token'
    client-id: 'console'
    client-secret: '{{ client_secret }}'# Web UI configuration
console:
  ui:
    canonical-url: 'http://{{ fqdn }}:1885/console'
    is:
      base-url: 'http://{{ fqdn }}:1885/api/v3'
    gs:
      base-url: 'http://{{ fqdn }}:1885/api/v3'
    ns:
      base-url: 'http://{{ fqdn }}:1885/api/v3'
    as:
      base-url: 'http://{{ fqdn }}:1885/api/v3'
    js:
      base-url: 'http://{{ fqdn }}:1885/api/v3'
    qrg:
      base-url: 'http://{{ fqdn }}:1885/api/v3'
    edtc:
      base-url: 'http://{{ fqdn }}:1885/api/v3'

  oauth:
    authorize-url: 'http://{{ fqdn }}:1885/oauth/authorize'
    token-url: 'http://{{ fqdn }}:1885/oauth/token'
    client-id: 'console'
    client-secret: '{{ client_secret }}'

@KrishnaIyer

Exactly. The above looks correct.

@jceloria

Thank you, that was in fact what I needed. After you had mentioned it, I came across #1752. If anyone is curious, this is the scrubbed & stripped down Ansible role that I’m testing with: https://github.com/jceloria/ansible-ttn-stack

Thanks again for everyone’s help.

We met an issue about openldap + openssl.

when a multithread client(30 threads) did connect to OPENLDAP server, the server side has «Bad Record MAC» error at TLS handshake randomly.

env
openldap+openssl TLS
RHEL7.5 openssl 1.0.2k
openldap2.4.43

TLS configure
The TLS configures are: TLS1.2 ,  ssf=128 and Cipher_Suite="AES:!NULL:!EXPORT" 

Error connection
Error connection progress are
client->server: Client Hello
server->client:Server Hello, Certificate, Server Hello Done
client->server: Client key Exchange
client->server: change cipher spec
client->server: Encryted Handshake Message
Server->client: Alert(Level: Fatal, Decription: Bad Record MAC)env
openldap+openssl TLS
RHEL7.5 openssl 1.0.2k
openldap2.4.43

when
when a multithread client(30 threads) connects OPENLDAP server, server side has «Bad Record MAC» error at TLS handshake
.
how frequence
This issue occurs randomly, for part connections.

TLS configure
The TLS configures are: TLS1.2 ,  ssf=128 and    Cipher_Suite="AES:!NULL:!EXPORT" 

Error connection
Error connection progress are
client->server: Client Hello
server->client:Server Hello, Certificate, Server Hello Done
client->server: Client key Exchange
client->server: change cipher spec
client->server: Encryted Handshake Message
Server->client: Alert(Level: Fatal, Decription: Bad Record MAC)

Источник

Понравилась статья? Поделить с друзьями:
  • Imap ошибка протокола tls неверная запись mac decryptaead
  • Imap код ошибки 4 ответ сервера capability completed
  • Imap yandex ru ошибка при проверке
  • Imap gmail com на айфоне ошибка
  • Image file execution options ошибка