OpenVPN username-as-common-name: dlaczego sprawdzenie CN jest puste
Skrypt client-connect, który porównuje common_name z username, może porównywać nazwę z nią samą. Powiąż certyfikat z kontem, zanim nastąpi zamiana.
Dodajesz skrypt client-connect, który odrzuca każde połączenie, w którym common_name różni się od username, i wygląda to jak powiązanie certyfikatu z kontem. Na serwerze z włączonym username-as-common-name to porównanie straciło już sens, zanim skrypt się uruchomi. Obie wartości to ten sam ciąg znaków, więc test przechodzi dla certyfikatu wydanego zupełnie komu innemu.
Sprawdzenie nie jest błędne dlatego, że skrypt jest źle napisany. Jest błędne dlatego, że czytana przez niego wartość została podmieniona wcześniej w tym samym połączeniu.
Co porównanie zdaje się udowadniać
Uwierzytelnianie certyfikatem i uwierzytelnianie hasłem to osobne dowody, a serwer może wymagać obu, nie wymagając, by należały do tej samej osoby. Luka jest realna: ważny certyfikat urządzenia plus dowolne ważne konto to inne twierdzenie niż ten certyfikat plus jedno nazwane konto. Skrypt porównujący common_name z username czyta się jak brakujące ogniwo między nimi. Byłby nim, gdyby common_name nadal oznaczało to, co mówił certyfikat.
Czy tak jest, zależy od jednej opcji serwera, a tę opcję zwykle włącza się z niepowiązanego powodu, na przykład aby łatwiej nazywać pliki konfiguracji dla poszczególnych użytkowników.
Co username-as-common-name robi z nazwą
Po włączeniu username-as-common-name OpenVPN zastępuje nazwę wspólną certyfikatu uwierzytelnioną nazwą użytkownika po zweryfikowaniu nazwy użytkownika i hasła. Hak weryfikacji uruchamiany podczas tego sprawdzenia nadal otrzymuje nazwę wspólną certyfikatu, ponieważ zamiana jeszcze nie nastąpiła. Wszystko później, łącznie z client-connect, widzi nazwę użytkownika. Dlatego późniejsze wywołanie zwrotne otrzymuje jedną tożsamość dwa razy i nie może jej porównać z przedstawionym certyfikatem.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
Prześledź jedno przykładowe połączenie: certyfikat wydany dla bob-device, udane logowanie do katalogu jako alice i włączona opcja. Faza weryfikacji wciąż może zobaczyć dwa różne ciągi znaków. Faza połączenia widzi alice i alice.
Ten przykład pokazuje, dlaczego porównanie jest puste. Nie pokazuje, że połączenie zostałoby inaczej zaakceptowane, ponieważ walidacja certyfikatu i weryfikacja hasła nadal działają samodzielnie.
Umieść powiązanie tam, gdzie obie tożsamości jeszcze istnieją
Reguła musi być egzekwowana na etapie, który widzi tożsamość certyfikatu i konto jednocześnie, co w praktyce oznacza hak weryfikacji nazwy użytkownika i hasła lub załadowaną tam wtyczkę. Obsługiwana wtyczka, która już wykonuje weryfikację hasła, jest zwykle właściwym miejscem na dodanie reguły parowania, ponieważ zastąpienie jej porównaniem nazw usunęłoby sprawdzanie hasła całkowicie.
Zdefiniuj mapowanie przed napisaniem kodu, ponieważ równość rzadko jest prawdziwą polityką. Certyfikat często identyfikuje urządzenie, a logowanie identyfikuje osobę, i jedno urządzenie może legalnie obsługiwać kilka osób. Przechowuj relację w formie, której wydawanie kontrolujesz, i zdecyduj, co się dzieje przy zmianie nazwy, ponownym wydaniu i przy nazwach kwalifikowanych domeną. Zmiana na małe litery lub usunięcie prefiksu domeny bez zrozumienia katalogu może scalić dwa konta, które miały pozostać odrębne.
Pamiętaj, że opcja zmienia też, która konfiguracja dla poszczególnych klientów obowiązuje, ponieważ client-config-dir jest powiązana z nazwą wspólną.
Przetestuj parowanie z dwoma ważnymi poświadczeniami
Zacznij od pary, którą dopuszcza twoja polityka, i potwierdź, że się łączy. Następnie przedstaw ten sam ważny certyfikat z innym, ale poza tym ważnym kontem: ta próba musi się nie powieść i musi się nie powieść z powodu reguły parowania, a nie z powodu błędnie wpisanego hasła. Błędne hasło dowodzi, że sprawdzanie hasła działa, i nic nie mówi o regule między certyfikatem a kontem.
Sprawdź także ścieżki z brakującym certyfikatem i z nieprawidłowym certyfikatem oraz potwierdź, której tożsamości serwer używa do ustawień dla poszczególnych klientów. Jeśli jedynym sposobem na działanie porównania jest wyłączenie username-as-common-name, najpierw oszacuj koszt tej zmiany, ponieważ przenosi ona wyszukiwanie konfiguracji każdego klienta z powrotem na nazwę certyfikatu.