William Brown wrote:
> Just want to point out there are some security risks with ssf settings.
> I have documented these here:
>
> https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.html
Nice writeup. I always considered SSF values to be naive and somewhat
overrated. People expect too much when looking at these numbers -
especially regarding the "strength" of cryptographic algorithms which
changes over time anyway with new cryptanalysis results coming up.
Personally I always try to implement a TLS-is-must policy and prefer
LDAPS (with correct protocol and ciphersuites configured) over
LDAP/StartTLS to avoid this kind of pre-TLS leakage.
Yes, I deliberately ignore "LDAPS is deprecated". ;-]
Furthermore some LDAP server implementation (IIRC e.g. MS AD) refuse to
accept SASL/GSSAPI bind requests sent over TLS-secured channel. Which is
IMO also somewhat questionable.
Ciao, Michael.
> Thanks for that, in the end I gave up on TLS and just used SSL. Later when I
> try again, it'll be after upgrading both the provider and the consumer to
> the same versions. For now I'm using:
Warren you wimp!!! I understand, but do go back to it as StartTLS is a
standard, LDAP over SSL isn't.
Thanks.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie,
Aberdeenshire, AB51 8GL.
Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
Do you know we have our own VoIP provider called SureVoIP? See
http://www.surevoip.co.uk
Did you see our API news?
http://www.surevoip.co.uk/news-events/surevoip-launches-innovative-api
Le 13/09/2012 14:16, arun.sasi1(a)wipro.com a écrit :
> Hello Team,
>
> I have an issue with OpenLDAP TLS based replication
>
> Getting below error
> slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com Error,
> ldap_start_tls failed (-11)
> Sep 13 16:13:34 ae0043app05 slapd[2582]: do_syncrepl: rid=365 rc -11
> retrying
>
> I have openLDAP in Ubuntu 9.04 version 2.4.19 then I thought to updgrade
> it and first I upgraded on my consumer openldap server which I migrated
> to Ubuntu 12.04 and version 2.4.28.
>
> I have created the certificate for my consumer from existing server. but
> when I go for TLS based replication, the database is not syncing and it
> is synching when remove starttls=no
What does the master log say, and did you try a manual connection with
the same credentials from the slave to the master, using TLS ?
--
BOFH excuse #166:
/pub/lunch
Dat Duong <datduong2000(a)yahoo.com> writes:
> Hi Hauke,
>
> I still can't get TLS to work. Here is the error message.
>
> TLS certificate verification: Error, self signed certificate
> tls_write: want=7, written=7
> 0000: 15 03 01 00 02 02 30 ......0
> TLS trace: SSL3 alert write:fatal:unknown CA
> TLS trace: SSL_connect:error in SSLv3 read server certificate B
> TLS trace: SSL_connect:error in SSLv3 read server certificate B
> TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Please describe the parameters to create your certificate chain.
I presume you have not signed your certificates with a known
certificate authority.
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E
Il 18/11/2015 02:32, Quanah Gibson-Mount ha scritto:
> --On Tuesday, November 17, 2015 7:57 PM +0200 Fr3ddie
> <fr3ddie(a)fr3ddie.it> wrote:
>
>> Il 10/11/2015 13:06, Fr3ddie ha scritto:
>>> Hello to the list,
>>
>> Nobody has any hint?
>
> I suggest reading the code, because the answer is actually fairly
> obvious if you look at slapd-meta/config.c:
>
> "NAME 'olcMetaTargetConfig' "
> "MUST ( olcMetaSub $ olcDbURI ) "
>
> Yet you aren't using the olcMetaTargetConfig objectClass in your entry.
Thank you very much for your help Quanah.
Please excuse the delay, I have not been able to access the servers
to perform other tests during this period...
I tried your suggestion and read the code, as much as I could have been
able to.
Then I modified the ldif file in order to create the meta-DB and its sub-DBs
containing the URIs of the target servers (if I correctly understood):
version: 1
dn: olcDatabase={3}meta,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMetaConfig
olcDatabase: {3}meta
olcSuffix: dc=loc1,dc=root
olcSuffix: dc=loc2,dc=root
olcSuffix: dc=loc3,dc=root
olcDbConnTtl: 240
olcDbRebindAsUser: FALSE
dn: olcMetaSub={0}uri,olcDatabase={3}meta,cn=config
objectClass: olcConfig
objectClass: olcMetaTargetConfig
olcMetaSub: {0}uri
olcDbUri: "ldap://server-loc1.loc1.root/dc=loc1,dc=root"
olcDbIdAssertBind: bindmethod=simple
binddn="cn=admin,dc=loc1,dc=root" credentials=xxxxxxxxx starttls=yes
tls_reqcert=demand
dn: olcMetaSub={1}uri,olcDatabase={3}meta,cn=config
objectClass: olcConfig
objectClass: olcMetaTargetConfig
olcMetaSub: {1}uri
olcDbUri: "ldap://server-loc2.loc2.root/dc=loc2,dc=root"
olcDbIdAssertBind: bindmethod=simple
binddn="cn=admin,dc=loc2,dc=root" credentials=xxxxxxxxx starttls=yes
tls_reqcert=demand
[...]
Modifying the ldif file as such I'm able to load it into the DB with no
complains by
slapd.
The problem is that I'm still unable to see the remote DITs using, e.g.,
Apache Directory Studio;
the log on the server reports this:
Mar 1 12:40:08 server-loc0 slapd[1210]: conn=149188 op=9
meta_search_dobind_init[0] mc=0xa119b38: non-empty dn with empty cred;
binding anonymously
On the target server the log reports nothing.
It seems slapd is ignoring my configuration for authentication to remote
targets (olcDbIdAssertBind): what can I try now?
Is it possible that this is a bug or, instead, it's still my
misconfiguration?
Thank you again for your help
btb(a)bitrate.net wrote:
>
> On Oct 2, 2013, at 11.47, Michael Ströder <michael(a)stroeder.com> wrote:
>
>> btb wrote:
>>> On 2013.10.02 07.29, Axel Grosse wrote:
>>>
>>>> when I test on the server itself ..
>>>> openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile
>>>> ./ssl/VordelCA.crt
>>>> CONNECTED(00000003)
>>>> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>>>> failure:s23_lib.c:188:
>>>
>>> ldaps [port 636] is deprecated.
>>> use starttls with the standard port [389].
>>> to test, just use ldapsearch [see the reference to -Z in the man page]
>>
>> This is nonsense.
>>
>> From a security perspective there's no reason not to use LDAPS. Well, I'd even
>> recommend LDAPS since SSL/TLS handshake is done *before* a client can send an
>> LDAP PDU.
>> With my deployments I always enable both but prefer LDAPS.
>>
>> I cannot imagine that any LDAP server or client will ever drop support for
>> LDAPS since this would immediately rule out this implementation from broader
>> market share.
>
> i'm not sure what exactly you mean by "this is nonsense". ldaps was never
> offered as a formal specification, and *is* deprecated.
I don't know of any document forbidding use of LDAPS.
I don't know any server which implements StartTLS which is not capable of
LDAPS (despite configuration choice).
> that's a fact: http://www.openldap.org/faq/data/cache/605.html .
FAQ entries are no formal specification. But you should read all of the FAQ:
"Although there is no technical specification for ldaps:// it is widely used."
> ldaps may well be in continued use even given its deprecation, but no one
> is debating that, and it's continued use in light of being deprecated does
> not change that it's deprecated. we all know it's still heavily used, and
> probably will continue to be for, at the very least, quite some time.
And because it's heavily used it's nonsense to teach everybody this pseudo
argument about "deprecated". And as said I find it even to be more secure.
Ciao, Michael.
> Am 2017-03-20 16:18, schrieb Dan White:
>> On 03/20/17 16:06 +0100, info(a)gwarband.de wrote:
>>> I don't have any idea how to set a higher debug level to dovecot. In
>>> my opinion I have the highest. So I can't deliver a greater log.
>>
>> I recommend consulting Dovecot's advice on how to run a debugger, or
>> dig
>> into the code which calls libldap.
> There isn't too much to "debug" in Dovecot's TLS implementation, it's
> not doing anything fancy asides from calling the ldap_start_tls_s.
>
> I am not sure what debugging you could try further.
>
> Aki
This was the answer of the dovecot mailing list.
Maybe it would be possible that people from this mailinglist
communicate directly with the dovecot mailinglist to find the soulution
together and easier.
Thanks
Tobias
Joshua Schaeffer wrote:
> On 02/18/2016 03:19 AM, Dieter Klünter wrote:
>> ssf=x specifies the overall security, a value '1' enables security.
>> This setting would meet your requirements:
>> olcSecurity: ssf=1 sasl=56 tls=256
>
> I updated olcSecurity
To the exact value Dieter mentioned above?
> and now I get the following when using simple auth:
>
> root@immortal:/var/log/kerberos# ldapsearch -LLL -x -D
> cn=admin,dc=harmonywave,dc=com -W -H
> ldap://baneling.harmonywave.com/????starttls -b dc=harmonywave,dc=com
> Enter LDAP Password:
> ldap_bind: Confidentiality required (13)
> additional info: SASL confidentiality required
You're not using a SASL bind mech at all. So no wonder why it fails due to sasl=56.
Do not guess. Read the man page for the exact meaning of all this.
Ciao, Michael.
--On Sunday, March 27, 2016 8:15 PM -0400 Xavier Landreville
<xavier(a)openconcept.ca> wrote:
>
>
>
> Hello,
>
> I am currently in the grips of trying to get syncrepl replication working
> with StartTLS. It was working fine until recently. The only change that
> occurred over the last 12 months (that relates to OpenLDAP) is that I've
> started requiring TLS for connections.
>
> My provider is running OpenLDAP 2.4.31 on Ubuntu 14.04, while one
> consumer is running the exact same version on a Ubuntu 14.04 machine and
> the other consumer is running OpenLDAP 2.4.28 on Ubuntu 12.04.
>
> Is there anything that I'm missing?
Probably a lot of data, given the fact you're doing replication with
verions known to be broken in regard to replication...
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
A division of Synacor, Inc
HI!
We're using self-compiled OpenLDAP 2.4.27 under RHEL 6.1 linked against
OpenSSL 1.0.0 libs shipped with RHEL.
(some names are consistently obfuscated herein to keep real names confidential)
Unfortunately we can't get StartTLS to work. It always fails:
# /opt/xxxdir/bin/ldapsearch -x -ZZ ldap://ldap-srv01.rz.domain
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate
# /opt/xxxdir/bin/ldapsearch -x -ZZ ldap://ldap.domain
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate
But OpenSSL lists the (IMO correct) hostnames in the server's certificate:
---------------------------------- snip ----------------------------------
Subject: CN=ldap.domain,OU=xxx,O=xxx,C=DE
[..]
X509v3 Subject Alternative Name:
email:certificate@xxx.domain,
DNS:ldap.domain,
DNS:ldap-srv01.rz.domain,
DNS:ldap-srv02.rz.domain
---------------------------------- snip ----------------------------------
Is the hostname check confused by the email in the first subjectAltName
sequence value?
Ciao, Michael.
