Your message dated Thu, 15 Feb 2018 11:22:33 +0200
with message-id <SWEDEN7027b8dab38d470f834c4d3dad5dde88@SWEDEN>
and subject line Direktoriaus kontaktai - tai Jūsų klientas
has caused the Debian Bug report #737921,
regarding gnutls unusable with cacert SHA2-512 sigs
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
737921: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libgnutls26
Severity: serious
Version: 2.12.20-8
cacert.org recently started signing certs with sha512WithRSAEncryption
Consider the following scenario:
- some service running on a Debian stable (wheezy) host (e.g. slapd),
admin replaces their cacert certificate with one of these new certs
- clients (e.g. PAM LDAP module, Apache mod_authnz_ldap) on Debian hosts
linked against gnutls
Everything stops working when the replacement certificate is installed
Troubleshooting, the following is observed:
- running ldapsearch or similar commands, the user sees errors like:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
or with "-d 1" for debugging, there is more detail but it doesn't help:
TLS: can't connect: A TLS packet with unexpected length was received..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
- the user then tries openssl s_client
openssl s_client -connect ldap-host.example.org:636 -tls1 -CAfile
/etc/ssl/certs/cacert.org.pem
and it connects successfully
- if the user also tries gnutls-cli however, it does not work, failing
with errors like this:
GnuTLS error: A TLS packet with unexpected length was received.
- then the admin tries putting their server (e.g. slapd) in debug mode
and sees errors like this
Could not negotiate a supported cipher suite
- the fact that openssl s_client worked and gnutls-cli did not work may
leave them feeling it is gnutls problems again (a Google search finds
plenty of old posts complaining about gnutls and suggesting people
should recompile everything with openssl)
- running gnutls-cli in debug mode, I notice the following:
$ gnutls-cli -p 636 --priority NORMAL:+SIGN-RSA-SHA512 -d 255
ldap-host.example.org
|<2>| EXT[SIGA]: sent signature algo (4.2) DSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (4.1) RSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (2.1) RSA-SHA1
|<2>| EXT[SIGA]: sent signature algo (2.2) DSA-SHA1
Even explicitly requesting SHA512 doesn't help:
gnutls-cli -p 636 --priority NORMAL:+SIGN-RSA-SHA512 -d 255
ldap-host.example.org
It seems that the gnutls client code in wheezy does not signal support
for the SHA512 stuff in the client hello message even if it is requested
in the cipher suite
$ gnutls-cli --list | grep 512
MACs: SHA1, MD5, SHA256, SHA384, SHA512, MD2, RIPEMD160, MAC-NULL
PK-signatures: SIGN-RSA-SHA1, SIGN-RSA-SHA224, SIGN-RSA-SHA256,
SIGN-RSA-SHA384, SIGN-RSA-SHA512, SIGN-RSA-RMD160, SIGN-DSA-SHA1,
SIGN-DSA-SHA224, SIGN-DSA-SHA256, SIGN-RSA-MD5, SIGN-RSA-MD2
suggests that the RSA-SHA512 is present and should work, but it doesn't
This is likely to be particularly annoying for people to troubleshoot,
especially if they have only allocated 5-10 minutes to replace their
certificate and they end up spending hours digging through their logs
and pulling their hair out before they realize what is wrong
Looking at the connections with tcpdump, I notice:
- client sends SSL client hello
- server drops connection without sending more data back to client
A suggested workaround is for the admin to create their own local root
CA instead of relying on CA cert. That means that the admin can ensure
that any changes to CA policy (e.g. using SHA512) are tested before
being forced on people.
--- End Message ---
--- Begin Message ---
Laba diena,
Noriu Jus informuoti apie šių metų pasikeitimą dėl atnaujintos visos Lietuvos
įmonių bazės 2018 metų sausio vidurio.
Visi juridiniai asmenys pateikti bazėje yra veikiantys, realiai vykdantys
veiklą, turintys įdarbintų darbuotojų. Duomenys pagal Sodrą, Registrų centrą.
Bazėje nurodoma ir apyvarta, darbuotojų atlyginimai, darbuotojų skaičius,
transporto skaičius ir daug kitų duomenų, kuriuos matysite pavyzdyje.
Duomenis galima filtruoti pagal veiklas, miestus ir kitus duomenis.
Šią bazę verta turėti visoms įmonėms. Pateiksiu priežastis:
1) Kontaktai pateikti bazėje direktorių ir kitų atsakingų asmenų, didelė
tikimybė Jums surasti naujų klientų, partnerių, tiekėjų, kai tiesiogiai
bendrausite su direktoriais, komercijos vadovais.
2) Konkurentų analizavimas, tiekėjų atsirinkimas pagal Jums reikalingus
kriterijus, galite atsifiltruoti pagal įmonės dydį, bazėje nurodoma kiek įmonės
skolingos Sodrai.
3) Lengva, greita ir patogu dirbti su šia baze, elektroninius pašto adresus
galite importuoti į elektroninių laiškų siuntimo programas ar sistemas iš kurių
siunčiate elektroninius laiškus.
Taip pat galite importuoti mobiliųjų telefonų numerius į SMS siuntimo programas.
Išsirinkite iš "Veiklų sąrašo" veiklas kurių Jums reikia.
( Sąrašas prisegtas laiške excel faile )
Parašykite, kurias veiklas išsirinkote
ir atsiųsime pavyzdį ir pasiūlymą su sąlygomis įmonių bazei įsigyti
Pagarbiai,
Tadas Giedraitis
Tel. nr. +37067881041
Veiklos.xlsx
Description: Binary data
--- End Message ---
