LDAP SSL (tcp.port==636) ε και;

Τις περισσ?τερες φορ?ς που συναντ?με εφαρμογ? η οπο?α χρει?ζεται να επικοινων?σει με DC μ?σω ldap (389 tcp) τ?τε το προτιμ?τερο ε?ναι να χρησιμοποι?σουμε το secure ldap ? ldap ssl ?στε να προστεθε? ?να παραπ?νω layer που θα παρ?χει encryption ?ρα και ασφ?λεια στην επικοινων?α. Το ldap ε?ναι ?πως φα?νεται και απ? τα παραπ?νω clear text protocol ?ρα αν ?χετε στ?σει το ν?ο σας proxy, web service etc το οπο?ο χρησιμοποιε? ldap για να κ?νει authenticate τους χρ?στες ε?ναι σ?γουρο πως αν κ?ποιος κ?νει trace στο ενδι?μεσο τ?τε ?χει πολλο?ς κωδικο?ς να μαζ?ψει.

Κ?τι ακ?μα που συναντ?ω συχν? ε?ναι πως ?ταν υπ?ρχει απα?τηση να δοθε? στην εφαρμογ? username/password για τα ldap queries δ?νεται ε?κολα Domain Admin account, φανταστε?τε λοιπ?ν πως ?ταν το Admin account κ?νει authentication, simple bind ?πως λ?γεται στο ldap protocol, τα username/password θα ταξιδ?ψουν απ? την μ?α μερι? στην ?λλη σε μορφ? clear text.

Για να φτ?σω στο προκε?μενο, βρ?σκομαι μια μ?ρα σε πελ?τη ?που υπ?ρχει εγκατεστημ?νο web service (?χι Microsoft) το οπο?ο χρησιμοποιε? secure ldap για να πιστοποι?σει τους χρ?στες που κ?νουν login. Για την υλοπο?ηση του secure ldap χρησιμοποιε?ται certificate ?πως και στην περ?πτωση του https. Τα πιστοποιητικ? ?μως ξ?ρετε ?χουν την κακ? συν?θεια να λ?γουν και να μας κ?νουν τη ζω? δ?σκολη. Εμε?ς β?βαια ως αν?τερα ?ντα δεν ασχολο?μαστε με αυτ? παρ? μ?νο αφο? λ?ξουν! ?τσι λοιπ?ν στο συγκεκριμ?νο πελ?τη ?ληξε το πιστοποιητικ? και πα?ει να λειτουργε? ο μηχανισμ?ς authentication με αποτ?λεσμα το portal για τους εξωτερικο?ς συνεργ?τες να μην λειτουργε? πλ?ον.

Χαμ?ς! Επιπλ?ον οι διαχειριστ?ς, ?χοντας “πλ?ρη” γν?ση της υποδομ?ς αποφασ?ζουν μ?σα σε ?λα να αλλ?ξουν και τον κωδικ? του χρ?στη που χρησιμοποιε?ται για τα ldap queries. O κωδικ?ς ?λλαξε για το χρ?στη στο AD και ενημερ?θηκε αντ?στοιχα στο web service του portal μ?σω κ?ποιας web φ?ρμας.

Ο πελ?της με τη βο?θεια μας καταλαβα?νει πως το πρ?βλημα προ?ρχεται απ? το ληγμ?νο πιστοποιητικ? οπ?τε και ξεκιν?ει η διαδικασ?α και εκδ?δεται ν?ο σ?μφωνα με το ?ρθρο

How to enable LDAP over SSL with a third-party certification authority

Εγκαθ?σταται λοιπ?ν στον DC και οι διαχειριστ?ς περιμ?νουν να επιστρ?ψουν στις δουλει?ς τους για ακ?μα 1 χρ?νο μ?χρι να λ?ξει κι αυτ?, ?μως αναπ?ντεχα κ?τι συνεχ?ζει να μην πηγα?νει καλ? και το authentication των χρηστ?ν συνεχ?ζει να αποτυγχ?νει!

Μιλ?ντας με ανθρ?πους που γνωρ?ζουν το web service το πρ?βλημα δε?χνει να προ?ρχεται απ? την εφαρμογ? που περι?ργως ?χει κρατ?σει τον παλι? κωδικ? παρ?λο που ?χουν ενημερωθε? ?λα τα απαρα?τητα config files με τον ν?ο κωδικ?.  Δυστυχ?ς τον παλι? κωδικ? δεν τον θυμ?ται κανε?ς οπ?τε κι εδ? φτ?νουμε σε αδι?ξοδο!

Εδ? λοιπ?ν αναλαμβ?νω δρ?ση και γνωρ?ζοντας πως το πιστοποιητικ? ε?ναι exportable το εξ?γω μαζ? με το Private Key και κ?νω decrypt ?πως φα?νεται παρακ?τω.

Εδ? φα?νονται τα SSL commands που χρησιμοποιο?νται για την επ?τευξη της κρυπτογρ?φησης Client Hello, Server Hello, Certificate κ.ο.κ. Επ?σης ?πειτα βλ?πουμε το κομμ?τι Application Data ?που εκε? στην ουσ?α ε?ναι τα κρυπτογραφημ?να δεδομ?να.

Ο Server αποστ?λλει το certificate

Εν? εδ? φα?νεται το “follow tcp stream” της επικοινων?ας ?που στην ουσ?α ?λα ε?ναι encrypted, εκτ?ς των SSL commands που φα?νονται στην κορυφ?.

Για να λ?σω το πρ?βλημα κ?νω τα εξ?ς, μετατρ?πω το certificate απ? μορφ? .pfx σε αρχε?ο τ?που .pem. Αυτ? επιτυγχ?νεται με το Openssl for Windows ?που εκτελο?με την εντολ?

openssl pkcs12 -in c:\temp\ldaps.pfx -out c:\temp\ldaps.pem -nodes –nocerts ?που in ε?ναι το πιστοποιητικ? που ?χουμε και αντ?στοιχα out ε?ναι αυτ? που θα παραχθε?.

Η ?λη διαδικασ?α γ?νεται επειδ? στο pfx υπ?ρχει το Private Key αλλ? ε?ναι κλειδωμ?νο το αρχε?ο με κωδικ? εν? το pem ?χει το Private Key χωρ?ς να ?χει κ?ποιο κωδικ? το αρχε?ο. To Wireshark δεν μπορε? να διαβ?σει pfx αλλ? pem αρχε?α. Οπ?τε λοιπ?ν αφο? π?ρουμε το pem file π?με στο Wireshark –> Edit –> Preferences –> Protocols –> SSL και προσθ?τουμε τα παρακ?τω

Εδ? λ?με πως θα προσπαθ?σει να κ?νει decrypt για ?λες τις IPs (ε?ναι το πιο ασφαλ?ς), στην tcp port 636, αυτ? που θα κ?νει decrypt ε?ναι ldap και τ?λος που βρ?σκεται το certificate. * Προσοχ? στο τα διαχωριστικ? ε?ναι κ?μματα (,)

Εκε? λοιπ?ν που πριν δεν μπορο?σαμε να διαβ?σουμε τ?ποτα τ?ρα ε?ναι

Προσ?ξτε ?τι εκτ?ς απ? το SSL Handshake ?χουμε το ldap command bind (ldap authentication), οπ?τε αν π?με στα περιεχ?μενα του bindrequest

?που το password φα?νεται πως ε?ναι το “P@ssw0rd”.

Για να επιστρ?ψω π?σω στο αρχικ? πρ?βλημα ?ντως η εφαρμογ? ε?χε “κολλ?σει” με τον παλι? κωδικ? που τον βρ?καμε ?τσι και κ?ναμε εκ ν?ου password reset στο χρ?στη στο AD και ?τσι λ?θηκε το πρ?βλημα. Δεν απαντ?θηκε β?βαια για ποιο λ?γο ε?χε κολλ?σει η εφαρμογ? αλλ? τουλ?χιστον το σ?στημα ?ταν π?λι παραγωγικ? και υπ?ρχε ?νετος χρ?νος για διερε?νηση. Β?βαια ο ενθουσιασμ?ς των διαχειριστ?ν ?ταν τερ?στιος και σε αυτ? συν?βαλλε η ε?ρεση του κρυπτογραφημ?νου κωδικο?, κ?τι που γενικ? συναρπ?ζει τον κ?σμο.

Κλε?νοντας να αναφ?ρω πως και τον Netmon μπορε? να κ?νει SSL Decrypt με τη χρ?ση του NMDecrypt (https://nmdecrypt.codeplex.com/releases/view/61943) και μ?λιστα κ?νοντας απ’ ευθε?ας χρ?ση του pfx file γνωρ?ζοντας β?βαια τον κωδικ?. Το αρνητικ? ε?ναι πως δεν ε?ναι real-time αλλ? χρει?ζεται η κ?νηση να ε?ναι αποθηκευμ?νη σε .cap εκ των προτ?ρων.