Re: (ITS#8211) ssf does not reflect actual security of connection
by hyc＠symas.com
hkario(a)redhat.com wrote:
> Full_Name: Hubert Kario
> Version: all
> OS: Linux
> URL:
> Submission from: (NULL) (213.175.37.10)
>
>
> Section "14.2.1. Security Strength Factors"[1] states "A SSF greater than one
> (>1) roughly correlates to the effective encryption key length.". This is not
> the case more often than not.
>
> Problem is that ssf as it is calculated now doesn't take into consideration
> all the cryptographic primitives in use.
>
> In other words, a connection that uses a 512 bit RSA certificates and
> negotiates TLS_RSA_WITH_AES_128_CBC_SHA (AES256-SHA) certainly does not
> provide security equivalent to "modern strong ciphers"[2][3] and should be
> awarded "256".
>
> Similarly a connection that uses 512 bit DH parameters and negotiates
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA (DHE-RSA-AES256-SHA) does not provide
> security that should be awarded "256"[5].
>
> In fact, recommending use of high key sizes[2] will cause the connection to
> use _less_ secure CBC ciphersuites[5] with clients that support AEAD
> ciphersuites with AES-128 only (like Thunderbird and Firefox do).
>
> Section 8.4.9[2] also calls RC4 a "modern strong cipher", most cryptographers
> disagree[6].
>
>
> So I think either:
> 1). ssf needs to be redefined to consider any value higher that "2" to be
> equal, and requiring the server administrators to enable only
> ciphersuites they consider secure, or
> 2). the whole code that calculates ssf needs to be updated to take into
> account many more things:
> * use of AEAD
> * use of Encrypt-then-MAC
> * the protocol version used (both because TLS1.0 specific attacks[7] as
> wewell as the use of SHA1+MD5 for signatures which limits the connection
> security to 80 bits[8] (optimistically) if client certificates are in
> use in TLS < 1.2)
> * encryption algorithm on session tickets
> * current state of attacks on a given ciphersuite
> * the size of ECDHE curve, FFDHE prime or server certificate key size,
> depending on ciphersuite negotiated
> * the signature algorithm used in Certificate Verify message
> * the key size of client certificate
> * the signature on the client certificate and key sizes in CA
> certificates
> * the HMAC used
> * key size of the symmetric cipher
> * (probably other things I didn't think about)
>
> 1 - http://www.openldap.org/doc/admin24/security.html
> 2 - http://w.w.openldap.org/doc/admin24/access-control.html section 8.4.9
> 3 - https://freakattack.com/
> 4 - https://weakdh.org/
> 5 - http://www.isg.rhul.ac.uk/tls/Lucky13.html
> 6 - https://tools.ietf.org/html/rfc7465
> 7 - https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack
> 8 - https://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf
Patch welcome. Either a doc patch describing your option (1) or a code patch
for your (2). Note that SSF generally comes to us from SASL, so a code patch
most likely needs to be submitted to the Cyrus-SASL Project, not us.
Overall the definition of SSF has been in use in the industry for many years;
it's not something we created or control. Changing the description or
definition of it likely needs to also happen elsewhere.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
Re: (ITS#8215) Slapmodify delete support and documentation
by hyc＠symas.com
ondra(a)mistotebe.net wrote:
> Full_Name: Ond&#345;ej Kuzn.k
> Version: master
> OS:
> URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150811-slapmodify-delete-...
> Submission from: (NULL) (62.84.155.99)
>
>
> It is only possible to delete entries in a back-ldif database. This patchset
> implements the equivalent functionality in the other core databases, enables the
> same in back-config and adds a slapmodify manpage. With that in place,
> test007-slapmodify is switched to fail on errors now. ModRDN stays unimplemented
> at this point.
>
> An outstanding issue is that valgrind complains about a memory leak in bdb on
> entry delete, which I have not been able to pinpoint nor fix.
Thanks. Committed to master. We'll keep this ITS open until the leak is fixed.
>
> The above patch is derived from OpenLDAP Software. All of the
> modifications to OpenLDAP Software represented in the above patches were
> developed by Ondřej Kuzník <ondra(a)mistotebe.net>. I have not assigned
> rights and/or interest in this work to any party.
>
> I, Ondřej Kuzník, hereby place the above modifications to OpenLDAP
> Software (and only these modifications) into the public domain. Hence,
> these modifications may be freely used and/or redistributed for any
> purpose with or without attribution and/or other notice.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
Re: (ITS#8216) Windows 'make test' failures
by hyc＠symas.com
mhardin(a)symas.com wrote:
> Full_Name: Matthew Hardin
> Version: 2.4.40
> OS: Windows 7/64
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (69.43.206.100)
>
>
> Many 'make test' test fail, for a variety of reasons, with LMDB and BDB/HDB
> backends.
>
> OpenLDAP 2.4.40
> Berkeley DB 4.8.30
>
>
> Environment:
> MSYS from MinGW/MSYS 2013072300
> Win-Builds MinGW 32- and 64-bit toolchain
>
> The following tests fail:
> test0-c-concurrency: problems reported by slapd-tester
> test039-glue-ldap-concurrency: seems to fail for the same reasons as test008
libtool incompatibility; it leaves shell scripts for the actual tester
programs in the progs directory, with the real executables under progs/.libs.
Windows' spawn can't execute shell scripts. Solution is to manually copy the
real executables from .libs before running the test.
Simple workaround. Won't fix this.
> test043-delta-syncrepl: lmdb always fails, hdb/bdb sometimes
Attribute ordering, the replicated data is correct. Won't fix this.
> test049-sync-config: config parsing problems
> test050-syncrepl-multimaster: config parsing problems
Fixed as ITS#8273
> test056-monitor: incorrect monitor output
Fixed as ITS#8280
> test058-syncrepl-asymmetric: parsing problems
> test059-slave-config: parsing problems
> test061-syncreplication-initiation: parsing prlelems
> test063-delta-multimaster: undetermined
> test064-constraint: include file processing (parsing?)
All ITS#8273.
Closing this ITS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
Re: (ITS#8267) contributing a new overlay unicodepw
by hyc＠symas.com
Ingo Voss wrote:
>
>
> Am 17.10.2015 um 20:58 schrieb Howard Chu:
>> ingo.voss(a)gmail.com wrote:
>>> Full_Name: Ingo Voss
>>> Version:
>>> OS:
>>> URL: ftp://ftp.openldap.org/incoming/contrib-slapd-modules-unicodepw.tar
>>> Submission from: (NULL) (78.53.86.212)
>>>
>>>
>>> Hello,
>>>
>>> I wrote a small overlay, that restricts all LDAP modification requests, so
>>> that
>>> only password changes for MS unicodePwd are possible.
>>> All other LDAP requests will not be observed.
>>> If someone needs a read-only proxy (in a e.g. dmz) for an MS Active Directory,
>>> but password changes must be possible, then unicodepw is the right overlay.
>>> For more informations, a manual page is included.
>>
>> If you want a read-only proxy, shouldn't this overlay also intercept and
>> deny all Add/Delete/ModDN requests?
>>
>
> Yes, you are right! But such overlay (denyop) exist already and it is working
> well.
> The manual page for unicodepw refers to denyop and describes the complete
> configuration in detail.
OK.
This code is full of C++ comments. OpenLDAP uses C comments only.
This code is full of SPACEs for indentation. OpenLDAP uses TAB characters for
indentation, with 4-column tab stops.
Your debug messages are using STATS debug level. STATS is reserved for LDAP
operation/parameter logging only and is the default level. Code should be
silent at the default level unless major errors have occurred.
This code cannot be accepted in its current form.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
Re: (ITS#8281) Syncrepl refresh failure when slapd is restarted midstream
by hyc＠symas.com
Michael Ströder wrote:
> hyc(a)symas.com wrote:
>> Michael Ströder wrote:
>>> hyc(a)symas.com wrote:
>>>> Michael Ströder wrote:
>>>>> hyc(a)symas.com wrote:
>>>>>> Generating a new contextCSN at startup is of questionable worth. We discussed
>>>>>> this a bit 'way back in 2004
>>>>>> http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perhaps we
>>>>>> should just not do it;
>>>>>
>>>>> +1
>>>>>
>>>>>> if a single-master provider starts up empty and a
>>>>>> consumer tries to talk to it and both have an empty cookie, the provider
>>>>>> should just respond "you're up to date".
>>>>>
>>>>> Why not return an error to the consumer?
>>>>
>>>> Typically if a consumer receives an error it will disconnect and retry later.
>>>> There's not much point making the consumer reconnect - which may be costly for
>>>> a TCP session. If it's a refreshAndPersist consumer, it just needs to hang on
>>>> and wait for some real data to arrive.
>>>
>>> Is the cost really that high compared to the rest of the initialization?
>>
>> I meant "TLS" there.
>
> As I'm solely using TLS secured LDAP connection *everywhere* I also implied
> TLS. Still I assume opening the syncrepl connection a few times again is
> nothing compared to the majority LDAP clients opening connections for every
> single LDAP simple bind request. So if it simplifies error handling which
> likely results in more robustness, I'd strongly prefer that.
As it turns out, it greatly simplified things to handle this condition as you
suggest. Fixed now in git master.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
Re: (ITS#8287) ldap server address book
by ikshafi＠yahoo.com
------=_Part_1734554_1852910388.1445610910369
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Dear=C2=A0Ciao, Michael
could you please refer any link ? =C2=A0i can not find anything regarding t=
his issue . please ..=C2=A0
=20
On Friday, October 23, 2015 3:10 AM, Michael Str=C3=B6der <michael@str=
oeder.com> wrote:
=20
ikshafi(a)yahoo.com wrote:
> Full_Name: sifat ara nil
> Version: 2.4.39
> OS: centros
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (103.230.63.94)
>=20
>=20
> I have create a Ldap server for Email address book purpose .Its running w=
ell and
> i am able to search by name . But it's not showing all address in microso=
ft
> outlook address book without search . how can i make it visible .=C2=A0=
=20
The ITS is for reporting bugs only.
You can ask usage questions on the openldap-technical mailing list.
For Outlook try to search for suitable LDAP attribute mappings.
It has been discussed numerous times before.
Ciao, Michael.
------=_Part_1734554_1852910388.1445610910369
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div style=3D"color:#000; background-color:#fff; f=
ont-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, =
sans-serif;font-size:16px"><div id=3D"yui_3_16_0_1_1445610560158_2897" dir=
=3D"ltr"><font face=3D"times new roman, new york, times, serif" id=3D"yui_3=
_16_0_1_1445610560158_3048">Dear <span style=3D"font-size: 13px;" id=
=3D"yui_3_16_0_1_1445610560158_2920" class=3D"">Ciao, M</span><span style=
=3D"font-size: 13px;" class=3D"" id=3D"yui_3_16_0_1_1445610560158_3035"><fo=
nt id=3D"yui_3_16_0_1_1445610560158_3034">icha</font></span><span style=3D"=
font-size: 13px;" class=3D"">el</span></font></div><div id=3D"yui_3_16_0_1_=
1445610560158_2896"><font face=3D"times new roman, new york, times, serif">=
<br></font></div><div dir=3D"ltr" id=3D"yui_3_16_0_1_1445610560158_2921"><f=
ont face=3D"times new roman, new york, times, serif" id=3D"yui_3_16_0_1_144=
5610560158_3050">could you please refer any link ? i can not find any=
thing regarding this issue . please .. </font><br></div> <br><div cla=
ss=3D"qtdSeparateBR"><br><br></div><div class=3D"yahoo_quoted" style=3D"dis=
play: block;"> <div style=3D"font-family: HelveticaNeue, Helvetica Neue, He=
lvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style=3D=
"font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grand=
e, sans-serif; font-size: 16px;"> <div dir=3D"ltr"> <font size=3D"2" face=
=3D"Arial"> On Friday, October 23, 2015 3:10 AM, Michael Str=C3=B6der <m=
ichael(a)stroeder.com> wrote:<br> </font> </div> <br><br> <div class=3D"y=
_msg_container"><a ymailto=3D"mailto:ikshafi@yahoo.com" href=3D"mailto:iksh=
afi(a)yahoo.com">ikshafi(a)yahoo.com</a> wrote:<br>> Full_Name: sifat ara ni=
l<br>> Version: 2.4.39<br>> OS: centros<br>> URL: <a href=3D"ftp:/=
/ftp.openldap.org/incoming/" target=3D"_blank">ftp://ftp.openldap.org/incom=
ing/</a><br>> Submission from: (NULL) (103.230.63.94)<br>> <br>> <=
br>> I have create a Ldap server for Email address book purpose .Its run=
ning well and<br>> i am able to search by name . But it's not showing al=
l address in microsoft<br>> outlook address book without search . how ca=
n i make it visible . <br><br>The ITS is for reporting bugs only.<br=
>You can ask usage questions on the openldap-technical mailing list.<br><br=
>For Outlook try to search for suitable LDAP attribute mappings.<br>It has =
been discussed numerous times before.<br><br>Ciao, Michael.<br><br><br></di=
v> </div> </div> </div></div></body></html>
------=_Part_1734554_1852910388.1445610910369--
7 years, 5 months
Re: (ITS#8281) Syncrepl refresh failure when slapd is restarted midstream
by michael＠stroeder.com
hyc(a)symas.com wrote:
> Michael Ströder wrote:
>> hyc(a)symas.com wrote:
>>> Michael Ströder wrote:
>>>> hyc(a)symas.com wrote:
>>>>> Generating a new contextCSN at startup is of questionable worth. We discussed
>>>>> this a bit 'way back in 2004
>>>>> http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perhaps we
>>>>> should just not do it;
>>>>
>>>> +1
>>>>
>>>>> if a single-master provider starts up empty and a
>>>>> consumer tries to talk to it and both have an empty cookie, the provider
>>>>> should just respond "you're up to date".
>>>>
>>>> Why not return an error to the consumer?
>>>
>>> Typically if a consumer receives an error it will disconnect and retry later.
>>> There's not much point making the consumer reconnect - which may be costly for
>>> a TCP session. If it's a refreshAndPersist consumer, it just needs to hang on
>>> and wait for some real data to arrive.
>>
>> Is the cost really that high compared to the rest of the initialization?
>
> I meant "TLS" there.
As I'm solely using TLS secured LDAP connection *everywhere* I also implied
TLS. Still I assume opening the syncrepl connection a few times again is
nothing compared to the majority LDAP clients opening connections for every
single LDAP simple bind request. So if it simplifies error handling which
likely results in more robustness, I'd strongly prefer that.
Ciao, Michael.
7 years, 5 months