Skip to content

Conversation

onceking
Copy link

@onceking onceking commented Jul 8, 2014

Something along the line of http://stackoverflow.com/questions/18453894/confused-about-ber-basic-encoding-rules

From the unpatched gem, the following LDAP "extended request"
with (1.3.6.1.4.1.1466.20037 LDAP_START_TLS_OID" is sent:

0000   fa 16 3e 91 ff 71 fa 16 3e 43 45 a0 08 00 45 00  ..>..q..>CE...E.
0010   00 53 e8 52 40 00 40 06 94 ab 01 7d 0c 85 ac 11  .S.R@.@....}....
0020   03 94 85 87 01 85 41 b9 73 45 3f 17 c3 ba 80 18  ......A.sE?.....
0030   01 c9 bd ec 00 00 01 01 08 0a 70 dc 9b 15 17 6b  ..........p....k
0040   1a e8 30 1d 02 01 01 77 18 04 16 31 2e 33 2e 36  ..0....w...1.3.6
0050   2e 31 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33  .1.4.1.1466.2003
0060   37                                               7

but the server would reset the connection and wireshark indicate the
'04' byte is invalid.

With ApacheDS, the request looks like the following:

0000   fa 16 3e 91 ff 71 fa 16 3e 43 45 a0 08 00 45 00  ..>..q..>CE...E.
0010   00 53 60 a8 40 00 40 06 3c bc 01 7d 0c 85 0a 7a  .S`.@.@.<..}...z
0020   84 c5 9d 9f 01 85 ad cb b4 99 bd ae b2 ef 80 18  ................
0030   01 c9 9d 86 00 00 01 01 08 0a 70 dc d4 40 17 6b  ..........p..@.k
0040   64 4c 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36  dL0....w...1.3.6
0050   2e 31 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33  .1.4.1.1466.2003
0060   37                                               7

This patch makes the request the same as ApacheDS' and worked fine.

Something along the line of http://stackoverflow.com/questions/18453894/confused-about-ber-basic-encoding-rules

From the unpatched gem, the following LDAP "extended request"
with (1.3.6.1.4.1.1466.20037 LDAP_START_TLS_OID" is sent:
========
0000   fa 16 3e 91 ff 71 fa 16 3e 43 45 a0 08 00 45 00  ..>..q..>CE...E.
0010   00 53 e8 52 40 00 40 06 94 ab 01 7d 0c 85 ac 11  .S.R@.@....}....
0020   03 94 85 87 01 85 41 b9 73 45 3f 17 c3 ba 80 18  ......A.sE?.....
0030   01 c9 bd ec 00 00 01 01 08 0a 70 dc 9b 15 17 6b  ..........p....k
0040   1a e8 30 1d 02 01 01 77 18 04 16 31 2e 33 2e 36  ..0....w...1.3.6
0050   2e 31 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33  .1.4.1.1466.2003
0060   37                                               7
========
but the server would reset the connection and wireshark indicate the
'04' byte is invalid.

With ApacheDS, the request looks like the following:
========
0000   fa 16 3e 91 ff 71 fa 16 3e 43 45 a0 08 00 45 00  ..>..q..>CE...E.
0010   00 53 60 a8 40 00 40 06 3c bc 01 7d 0c 85 0a 7a  .S`.@.@.<..}...z
0020   84 c5 9d 9f 01 85 ad cb b4 99 bd ae b2 ef 80 18  ................
0030   01 c9 9d 86 00 00 01 01 08 0a 70 dc d4 40 17 6b  ..........p..@.k
0040   64 4c 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36  dL0....w...1.3.6
0050   2e 31 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33  .1.4.1.1466.2003
0060   37                                               7
========

This patch makes the request the same as ApacheDS' and worked fine.
@cmdrclueless
Copy link
Contributor

I'm having a similar problem with Microsoft Active Directory and the StartTLS command. I developed the same fix independently before I saw this existing pull request.

The encoding as per section 4.14.2 of RFC 4511 states that the StartTLS command uses an ExtendedRequest documented in section 4.2 of the RFC. The extended request format is documented as

ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
             requestName      [0] LDAPOID,
             requestValue     [1] OCTET STRING OPTIONAL
}

Each element in the ExtendedRequest is implicitly tagged, and as defined in rules of ITU-T X.690 section 8.14 the requestName should be of type CONTEXT(0) even though an LDAPOID has a type UNIVERSAL(4). In the StartTLS context the requestValue is not sent, but if it were it would be CONTEXT(1) instead of UNIVERSAL(4).

schaary added a commit that referenced this pull request Aug 4, 2014
Fix net-ldap with start-tls.
@schaary schaary merged commit 5fd242c into ruby-ldap:master Aug 4, 2014
astratto pushed a commit to astratto/ruby-net-ldap that referenced this pull request Dec 18, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants