Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation: clarify difference between LDAP ports and security guarentees #708

Merged
merged 1 commit into from
Nov 29, 2016

Conversation

ericchiang
Copy link
Contributor

Now that LDAP supports an insecureSkipVerify option, clarify that
insecureNoTLS is an extremely bad choice and as such we may drop
support for 389 in the future.

However, since we send plain text passwords from our frontend to our
backend, this probably gets us into a bigger conversation about dex's
TLS story. For example when terminiation is approporate. cc'ing
@dghubble for thoughts on how that might apply to our internal uses.

We probably want an overaching security doc at some point, but that
can be another PR.

cc @ElijahCaine since this is a docs review.

…rantees

Now that LDAP supports an `insecureSkipVerify` option, clarify that
`insecureNoTLS` is an extremely bad choice and as such we may drop
support for 389 in the future.

However, since we send plain text passwords from our frontend to our
backend, this probably gets us into a bigger conversation about dex's
TLS story. For example when terminiation is approporate. cc'ing
@dghubble for thoughts on how that might apply to our internal uses.

We probably want an overaching security doc at some point, but that
can be another PR.
@ericchiang ericchiang merged commit e267dbd into dexidp:master Nov 29, 2016
@@ -9,25 +9,44 @@ The connector executes two primary queries:
1. Finding the user based on the end user's credentials.
2. Searching for groups using the user entry.

## Security considerations

Dex attempts to bind with the backing LDAP server using the end user's _plain text password_. Though some LDAP implementations allow passing hashed passwords, dex doesn't support hashing and instead _strongly recommends that all administrators just use TLS_. This can often be achieved by using port 636 instead of 389, and administrators that choose 389 are actively leaking passwords.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this actually correct? My understanding is that ldap with STARTTLS is on port 389, and that port 636 is for the older (and somewhat depcrecated?) LDAPS protocol, with a direct SSL transport.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you're correct. I think we never worked out the STARTTLS vv LDAPS strategy. Biggest goal of this section was to prevent users from just using port 389 without any encryption. Please feel free to send a follow up or open an issue if you're interested.

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.

2 participants