Re: (ITS#7867) TLS SHA512
by hyc＠symas.com
yann+openldap(a)verry.org wrote:
> Full_Name: Yann Verry
> Version: 2.4.39
> OS: debian/sid
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2a01:e35:2e6d:c800:d572:aec:1b42:380c)
This is purely a TLS issue, OpenLDAP has nothing to do with it. Ask for help
on a gnutls support forum. Closing this ITS.
>
>
> Hi,
>
> I would like (CACert sign class3 now with SHA512) to switch my X509 certificate
> with a signature algorithm SHA512.
> When I do this openldap bind on SSL port but was unable to provide SSL
> connection as you can see in error:
>
> 2014-05-31T00:20:46.852821+02:00 peach slapd[23997]: >>>
> slap_listener(ldaps:///)
> 2014-05-31T00:20:46.853369+02:00 peach slapd[23997]: connection_get(35): got
> connid=1068
> 2014-05-31T00:20:46.853891+02:00 peach slapd[23997]: connection_read(35):
> checking for input on id=1068
> 2014-05-31T00:20:46.854526+02:00 peach slapd[23997]: connection_read(35): TLS
> accept failure error=-1 id=1068, closing
> 2014-05-31T00:20:46.855071+02:00 peach slapd[23997]: connection_close: conn=1068
> sd=35
>
> If I fall back to sha256 it works fine
>
>
> How to reproduce
> ================
>
> - generate self signed with sha256 and sha512:
>
> mkdir -p /etc/ldap/ssl
> cd !$
>
> # priv
> certtool --generate-privkey --sec-param normal --outfile mypriv_normal.key
>
> # self
> certtool -s --load-privkey mypriv_normal.key --outfile gnutls512_normal.crt
> --hash SHA512
> certtool -s --load-privkey mypriv_normal.key --outfile gnutls256_normal.crt
> --hash SHA256
>
> # build PEM
> cat mypriv_normal.key gnutls512_normal.crt > gnutls512_normal.pem
> cat mypriv_normal.key gnutls256_normal.crt > gnutls256_normal.pem
>
>
> my cn=config:
>
> olcTLSCACertificateFile: /etc/ldap/ssl/sslcertificate.pem
> olcTLSCertificateFile: /etc/ldap/ssl/sslcertificate.pem
> olcTLSCertificateKeyFile: /etc/ldap/ssl/sslcertificate.pem
>
> now just play with symlink.
>
> sha256
> ------
>
> ln -s gnutls256_normal.pem sslcertificate.pem ; then restart openldap
>
> make a client connection:
>
> gnutls-cli ldap.verry.org -p 636
> Resolving 'ldap.verry.org'...
> Connecting to '2a01:e35:2e6d:c800:cafe:deca:0:42:636'...
> - Certificate type: X.509
> - Got a certificate list of 1 certificates.
> - Certificate[0] info:
> - subject `CN=ldap.verry.org', issuer `CN=ldap.verry.org', RSA key 2432 bits,
> signed using RSA-SHA256, activated `2014-05-31 08:26:59 UTC', expires
> `2024-05-28 08:27:03 UTC', SHA-1 fingerprint
> `600b2a502289644c075d4b3eaf7b1efd38685687'
> - The hostname in the certificate matches 'ldap.verry.org'.
> - Peer's certificate issuer is unknown
> - Peer's certificate is NOT trusted
> - Version: TLS1.2
> - Key Exchange: RSA
> - Cipher: AES-128-CBC
> - MAC: SHA1
> - Compression: NULL
> - Handshake was completed
>
> - Simple Client Mode:
>
>
> server view, it's OK:
>
> 538909bf conn=1007 fd=32 TLS established tls_ssf=256 ssf=256
>
>
>
> sha512
> ------
> rm previous symlink and ln -s gnutls512_normal.pem sslcertificate.pem ; then
> restart openldap
>
> make a connection:
>
> gnutls-cli ldap.verry.org -p 636
> Resolving 'ldap.verry.org'...
> Connecting to '2a01:e35:2e6d:c800:cafe:deca:0:42:636'...
> *** Fatal error: A TLS packet with unexpected length was received.
> *** Handshake has failed
> GnuTLS error: A TLS packet with unexpected length was received.
>
> server view:
>
> TLS: can't accept: Could not negotiate a supported cipher suite..
> 538909f9 connection_read(28): TLS accept failure error=-1 id=1000, closing
> 538909f9 connection_closing: readying conn=1000 sd=28 for close
> 538909f9 connection_close: conn=1000 sd=28
> 538909f9 daemon: removing 28
> 538909f9 conn=1000 fd=28 closed (TLS negotiation failure)
>
>
>
> gnutls
> ======
>
> gnutls-cli -l|grep SHA512
> MACs: SHA1, MD5, SHA256, SHA384, SHA512, SHA224, UMAC-96, UMAC-128, AEAD
> Digests: SHA1, MD5, SHA256, SHA384, SHA512, SHA224
> PK-signatures: SIGN-RSA-SHA1, SIGN-RSA-SHA1, SIGN-RSA-SHA224, SIGN-RSA-SHA256,
> SIGN-RSA-SHA384, SIGN-RSA-SHA512, SIGN-RSA-RMD160, SIGN-DSA-SHA1, SIGN-DSA-SHA1,
> SIGN-DSA-SHA224, SIGN-DSA-SHA256, SIGN-RSA-MD5, SIGN-RSA-MD5, SIGN-RSA-MD2,
> SIGN-ECDSA-SHA1, SIGN-ECDSA-SHA224, SIGN-ECDSA-SHA256, SIGN-ECDSA-SHA384,
> SIGN-ECDSA-SHA512
>
> I can provide more information as needed to solve this issue
>
> Regards,
> Yann
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years
(ITS#7867) TLS SHA512
by yann+openldap＠verry.org
Full_Name: Yann Verry
Version: 2.4.39
OS: debian/sid
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2a01:e35:2e6d:c800:d572:aec:1b42:380c)
Hi,
I would like (CACert sign class3 now with SHA512) to switch my X509 certificate
with a signature algorithm SHA512.
When I do this openldap bind on SSL port but was unable to provide SSL
connection as you can see in error:
2014-05-31T00:20:46.852821+02:00 peach slapd[23997]: >>>
slap_listener(ldaps:///)
2014-05-31T00:20:46.853369+02:00 peach slapd[23997]: connection_get(35): got
connid=1068
2014-05-31T00:20:46.853891+02:00 peach slapd[23997]: connection_read(35):
checking for input on id=1068
2014-05-31T00:20:46.854526+02:00 peach slapd[23997]: connection_read(35): TLS
accept failure error=-1 id=1068, closing
2014-05-31T00:20:46.855071+02:00 peach slapd[23997]: connection_close: conn=1068
sd=35
If I fall back to sha256 it works fine
How to reproduce
================
- generate self signed with sha256 and sha512:
mkdir -p /etc/ldap/ssl
cd !$
# priv
certtool --generate-privkey --sec-param normal --outfile mypriv_normal.key
# self
certtool -s --load-privkey mypriv_normal.key --outfile gnutls512_normal.crt
--hash SHA512
certtool -s --load-privkey mypriv_normal.key --outfile gnutls256_normal.crt
--hash SHA256
# build PEM
cat mypriv_normal.key gnutls512_normal.crt > gnutls512_normal.pem
cat mypriv_normal.key gnutls256_normal.crt > gnutls256_normal.pem
my cn=config:
olcTLSCACertificateFile: /etc/ldap/ssl/sslcertificate.pem
olcTLSCertificateFile: /etc/ldap/ssl/sslcertificate.pem
olcTLSCertificateKeyFile: /etc/ldap/ssl/sslcertificate.pem
now just play with symlink.
sha256
------
ln -s gnutls256_normal.pem sslcertificate.pem ; then restart openldap
make a client connection:
gnutls-cli ldap.verry.org -p 636
Resolving 'ldap.verry.org'...
Connecting to '2a01:e35:2e6d:c800:cafe:deca:0:42:636'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
- subject `CN=ldap.verry.org', issuer `CN=ldap.verry.org', RSA key 2432 bits,
signed using RSA-SHA256, activated `2014-05-31 08:26:59 UTC', expires
`2024-05-28 08:27:03 UTC', SHA-1 fingerprint
`600b2a502289644c075d4b3eaf7b1efd38685687'
- The hostname in the certificate matches 'ldap.verry.org'.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.2
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed
- Simple Client Mode:
server view, it's OK:
538909bf conn=1007 fd=32 TLS established tls_ssf=256 ssf=256
sha512
------
rm previous symlink and ln -s gnutls512_normal.pem sslcertificate.pem ; then
restart openldap
make a connection:
gnutls-cli ldap.verry.org -p 636
Resolving 'ldap.verry.org'...
Connecting to '2a01:e35:2e6d:c800:cafe:deca:0:42:636'...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GnuTLS error: A TLS packet with unexpected length was received.
server view:
TLS: can't accept: Could not negotiate a supported cipher suite..
538909f9 connection_read(28): TLS accept failure error=-1 id=1000, closing
538909f9 connection_closing: readying conn=1000 sd=28 for close
538909f9 connection_close: conn=1000 sd=28
538909f9 daemon: removing 28
538909f9 conn=1000 fd=28 closed (TLS negotiation failure)
gnutls
======
gnutls-cli -l|grep SHA512
MACs: SHA1, MD5, SHA256, SHA384, SHA512, SHA224, UMAC-96, UMAC-128, AEAD
Digests: SHA1, MD5, SHA256, SHA384, SHA512, SHA224
PK-signatures: SIGN-RSA-SHA1, SIGN-RSA-SHA1, SIGN-RSA-SHA224, SIGN-RSA-SHA256,
SIGN-RSA-SHA384, SIGN-RSA-SHA512, SIGN-RSA-RMD160, SIGN-DSA-SHA1, SIGN-DSA-SHA1,
SIGN-DSA-SHA224, SIGN-DSA-SHA256, SIGN-RSA-MD5, SIGN-RSA-MD5, SIGN-RSA-MD2,
SIGN-ECDSA-SHA1, SIGN-ECDSA-SHA224, SIGN-ECDSA-SHA256, SIGN-ECDSA-SHA384,
SIGN-ECDSA-SHA512
I can provide more information as needed to solve this issue
Regards,
Yann
9 years
Re: (ITS#7866) [PATCH] Mention default database in tools' man pages
by hyc＠symas.com
jsynacek(a)redhat.com wrote:
> Full_Name: Jan Synacek
> Version: 2.4.39
> OS:
> URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20140530-0001-Mention-...
> Submission from: (NULL) (209.132.186.34)
>
>
> Many of the slaptools use -b to specify a database. However, there is no mention
> (apart from section 10.2.1. "The slapadd program" in the admin guide) in the
> documentation that if there are multiple databases in the configuration, the
> first one is used when no -b is given. The provided patch tries to improve the
> situation by providing an explicit mention of the default database.
Seriously? In 15 years no one else has ever remarked on this, why is this even
worth discussing?
At any rate, the added text is incorrect. Technically, "the first database in
the configuration that supports the requested operation" is used. E.g., if
back-monitor is the first DB in the config, it is skipped.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years
Re: (ITS#7863) Invalid DN syntax (34) not written by slapo-accesslog
by pierangelo.masarati＠polimi.it
On 05/30/2014 01:33 AM, hyc(a)symas.com wrote:
> pierangelo.masarati(a)polimi.it wrote:
>> It now comes to my mind that another perhaps less intrusive chance of
>> intervention could be to act at the *response* level. Think of:
>>
>> - the possibility to stack code in the response chain (not necessarily
>> overlays)
>>
>> - have a way to understand if the response originates *before* the
>> frontend was called
>>
>> In this case, the custom code could re-parse the request to re-detect
>> why it failed and handle it (e.g. log custom information on failure
>> reason). Not a piece of cake, but probably less intrusive than other
>> options. (I'm not sure the raw request buffer is still available at
>> this stage, though.)
>
> Still not something useful for slapo-accesslog - we're storing log info as
> LDAP attributes. We can't store reqDN if the DN has invalid syntax. We can't
> store reqMod values if the attributetype is unknown or the values are invalid.
> When a request fails validation it's literally garbage, and toxic - cannot be
> considered safe to preserve in a DB.
Sure. Indeed, it could not be associated with accesslog (invalid DN
needs to be detected way before a database can be selected). Such a
case would belong to some "debugging" layer (e.g. client-server
interaction troubleshooting), which BTW I'm convinced the current
logging is more than enough for.
p.
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
9 years
Re: (ITS#7863) Invalid DN syntax (34) not written by slapo-accesslog
by hyc＠symas.com
pierangelo.masarati(a)polimi.it wrote:
> It now comes to my mind that another perhaps less intrusive chance of
> intervention could be to act at the *response* level. Think of:
>
> - the possibility to stack code in the response chain (not necessarily
> overlays)
>
> - have a way to understand if the response originates *before* the
> frontend was called
>
> In this case, the custom code could re-parse the request to re-detect
> why it failed and handle it (e.g. log custom information on failure
> reason). Not a piece of cake, but probably less intrusive than other
> options. (I'm not sure the raw request buffer is still available at
> this stage, though.)
Still not something useful for slapo-accesslog - we're storing log info as
LDAP attributes. We can't store reqDN if the DN has invalid syntax. We can't
store reqMod values if the attributetype is unknown or the values are invalid.
When a request fails validation it's literally garbage, and toxic - cannot be
considered safe to preserve in a DB.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years
Re: (ITS#7863) Invalid DN syntax (34) not written by slapo-accesslog
by pierangelo.masarati＠polimi.it
On 05/29/2014 09:31 PM, pierangelo.masarati(a)polimi.it wrote:
> On 05/29/2014 06:13 PM, michael(a)stroeder.com wrote:
>> Howard Chu wrote:
>>> michael(a)stroeder.com wrote:
>>>> It seems that modify requests which failed due to Invalid DN syntax (34) are
>>>> not
>>>> written to accesslog-DB. I guess that those requests get abandoned by the
>>>> frontend and never reach the backend at all.
>>>
>>> Correct.
>>>
>>>> It would be handy to see the invalid modify request in the accesslog-DB though.
>>>>
>>>> Any chance to achieve this?
>>>
>>> Not likely. The frontend must call select_backend() based on the incoming DN
>>> to determine which backend to invoke, and thus which stack of overlays are
>>> involved. If the DN is invalid, no selection can occur.
>>
>> Hmm, I've done some more tests. Invalid syntax (21) also does not make it
>> beyond the frontend into accesslog-DB.
>>
>> I have no clear opinion on this. Of course the current behaviour is good for
>> performance. But sometimes one would like to observe what broken LDAP clients
>> sent in a modify request in the past.
>>
>> Also running with BER loglevel or breaking up the TLS connection with stunnel
>> and sniff with Wireshark is not always an option.
>>
>> Having this configurable would be great.
>>
>> What's your opinion on this?
>
> In terms of code architecture, overlays have been designed to work on
> validated data (the request must be well formed). To this end, the
> notion of "frontend" database was added to make it possible to layer an
> overlay *before* backend selection.
>
> To have a custom piece of code muck with a request before it is
> validated (or even before it is parsed) you need to split the code into:
>
> - parsing, without doing any sanity check
>
> - allow custom code to step in
>
> - do validation afterwards
>
> This does not necessarily imply performance penalty (when no custom code
> steps in, the amount of operations would be the same for sane requests;
> in case of malformed requests, you would miss the opportunity to bail
> out on the first inconsistency).
>
> However, it would imply significant refactorization of the current code,
> without (IMHO) a strong motivation for it: malformed requests are
> already handled in terms of response to clients, and somehow logged.
>
> An (expensive) alternative would be to register a handler at connection
> level which duplicates the parsing to anticipate checking for errors
> that would be detected before passing control to the frontend. Not the
> way I'd go, unless strictly necessary.
>
> A paranoid but intriguing alternative would be to implement an operation
> mode that keeps parsing after the first error is detected, turning the
> operation into a no-op. Again, lots of refactorization and error
> handling and so on (for example, what if a syntax, an attribute
> description or a matching rule is not found? You'd always have to check
> that the corresponding pointer is not NULL before using it, whereas
> right now we often assume that if execution got there, data must be
> consistent. Of course, we could introduce dummy syntaxes
> "NonExistingSyntax", ..., but we'd probably need to define their
> semantics in such a way that they apply to every case we need to handle
> and so).
It now comes to my mind that another perhaps less intrusive chance of
intervention could be to act at the *response* level. Think of:
- the possibility to stack code in the response chain (not necessarily
overlays)
- have a way to understand if the response originates *before* the
frontend was called
In this case, the custom code could re-parse the request to re-detect
why it failed and handle it (e.g. log custom information on failure
reason). Not a piece of cake, but probably less intrusive than other
options. (I'm not sure the raw request buffer is still available at
this stage, though.)
p.
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
9 years
Re: (ITS#7863) Invalid DN syntax (34) not written by slapo-accesslog
by pierangelo.masarati＠polimi.it
On 05/29/2014 06:13 PM, michael(a)stroeder.com wrote:
> Howard Chu wrote:
>> michael(a)stroeder.com wrote:
>>> It seems that modify requests which failed due to Invalid DN syntax (34) are
>>> not
>>> written to accesslog-DB. I guess that those requests get abandoned by the
>>> frontend and never reach the backend at all.
>>
>> Correct.
>>
>>> It would be handy to see the invalid modify request in the accesslog-DB though.
>>>
>>> Any chance to achieve this?
>>
>> Not likely. The frontend must call select_backend() based on the incoming DN
>> to determine which backend to invoke, and thus which stack of overlays are
>> involved. If the DN is invalid, no selection can occur.
>
> Hmm, I've done some more tests. Invalid syntax (21) also does not make it
> beyond the frontend into accesslog-DB.
>
> I have no clear opinion on this. Of course the current behaviour is good for
> performance. But sometimes one would like to observe what broken LDAP clients
> sent in a modify request in the past.
>
> Also running with BER loglevel or breaking up the TLS connection with stunnel
> and sniff with Wireshark is not always an option.
>
> Having this configurable would be great.
>
> What's your opinion on this?
In terms of code architecture, overlays have been designed to work on
validated data (the request must be well formed). To this end, the
notion of "frontend" database was added to make it possible to layer an
overlay *before* backend selection.
To have a custom piece of code muck with a request before it is
validated (or even before it is parsed) you need to split the code into:
- parsing, without doing any sanity check
- allow custom code to step in
- do validation afterwards
This does not necessarily imply performance penalty (when no custom code
steps in, the amount of operations would be the same for sane requests;
in case of malformed requests, you would miss the opportunity to bail
out on the first inconsistency).
However, it would imply significant refactorization of the current code,
without (IMHO) a strong motivation for it: malformed requests are
already handled in terms of response to clients, and somehow logged.
An (expensive) alternative would be to register a handler at connection
level which duplicates the parsing to anticipate checking for errors
that would be detected before passing control to the frontend. Not the
way I'd go, unless strictly necessary.
A paranoid but intriguing alternative would be to implement an operation
mode that keeps parsing after the first error is detected, turning the
operation into a no-op. Again, lots of refactorization and error
handling and so on (for example, what if a syntax, an attribute
description or a matching rule is not found? You'd always have to check
that the corresponding pointer is not NULL before using it, whereas
right now we often assume that if execution got there, data must be
consistent. Of course, we could introduce dummy syntaxes
"NonExistingSyntax", ..., but we'd probably need to define their
semantics in such a way that they apply to every case we need to handle
and so).
My 2c.
p.
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
9 years
Re: (ITS#7863) Invalid DN syntax (34) not written by slapo-accesslog
by michael＠stroeder.com
Howard Chu wrote:
> michael(a)stroeder.com wrote:
>> It seems that modify requests which failed due to Invalid DN syntax (34) are
>> not
>> written to accesslog-DB. I guess that those requests get abandoned by the
>> frontend and never reach the backend at all.
>
> Correct.
>
>> It would be handy to see the invalid modify request in the accesslog-DB though.
>>
>> Any chance to achieve this?
>
> Not likely. The frontend must call select_backend() based on the incoming DN
> to determine which backend to invoke, and thus which stack of overlays are
> involved. If the DN is invalid, no selection can occur.
Hmm, I've done some more tests. Invalid syntax (21) also does not make it
beyond the frontend into accesslog-DB.
I have no clear opinion on this. Of course the current behaviour is good for
performance. But sometimes one would like to observe what broken LDAP clients
sent in a modify request in the past.
Also running with BER loglevel or breaking up the TLS connection with stunnel
and sniff with Wireshark is not always an option.
Having this configurable would be great.
What's your opinion on this?
Ciao, Michael.
9 years
