MySQL през VPN: проверете сървъра, а не само криптирането
Криптирането към грешен хост пак е грешно. Сравнете стойностите на ssl-mode, после изпълнете връзка, която назовава сървъра, който имате предвид, и го доказва.
Запазвате връзка към 10.20.4.15, VPN връзката пада, а клиентът продължава да се свързва. Това не е добра новина. Частният адрес е място в какъвто и да е контекст на маршрутизация, в който се намирате, и много мрежи използват едни и същи диапазони. Клиентът е достигнал MySQL сървър, просто може да не е вашият.
Поправката има две половини и само една от тях е за мрежата. Дръжте връзката по предназначения път и накарайте клиента да удостоверява сървъра, с който говори. Първата половина е там, където помага VPN; втората трябва да се конфигурира.
Криптирано към какво, точно?
TLS защитава разговора от всеки по средата и не казва нищо за това кой твърди, че е крайната точка, освен ако клиентът не проверява. Сертификат, който се валидира срещу доверен орган, доказва, че сертификатът е издаден от този орган. Той не доказва, че сертификатът е издаден за името на хоста, който сте искали да достигнете, а това са различни въпроси.
Това не е теоретична пропуск. Captive портали, грешки с грешен VRF и припокриващи се адресни планове всички създават сървър, който е напълно готов да преговаря с вас за TLS. Ако клиентът изисква само криптиране, сесията е частна и насочена към грешната база данни.
Значи уместният въпрос не е дали връзката е криптирана, а дали е криптирана към идентичността, която сте имали предвид. В клиента на MySQL тази разлика живее изцяло в настройката ssl-mode.
Петте стойности на ssl-mode на практика
Съществуват пет стойности и само една от тях отговаря на въпроса на това ръководство. Таблицата изброява какво всяка реално гарантира, а не какво подсказва името ѝ.
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
Само последният ред отговаря на въпроса в тази статия. PREFERRED заслужава отделно внимание, защото клиент, който тихо преминава към чист текст, е по-лош от такъв, който отказва: вярвате, че имате криптиране, а записът на пакетите не е съгласен.
Връзка, която можете да изпълните днес
Командата по-долу е формата, която да използвате, с два заместителя: одобреното име на базата данни и CA файл, получен по одобрен канал. Нито едно от двете не бива да се взема от това, което сървърът ви предложи при първи контакт.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password без стойност подканя за въвеждане, което пази тайната извън списъка с процеси и извън историята на черупката. Това е малък навик с голяма полза на споделени jump хостове, където командният ред е видим за други потребители.
Когато това се провали, текстът на грешката разграничава случаите по-добре от интуицията. Грешка с CA означава, че веригата не се валидира и трябва да гледате кой CA е подписал сертификата на сървъра. Грешка с име на хост означава, че веригата е наред, а името не съвпада, което обикновено значи, че сте се свързали с правилния сървър под грешно име, а не с грешния сървър.
Появата на подкана не е доказателство, че парола вече е предадена, а неуспешна връзка не доказва, че нищо не е напуснало клиента. Ако реконструирате минало събитие, идентифицирайте клиента, неговата конфигурация, плъгина за удостоверяване и етапа, който се е провалил. Оценката на излагането по последното съобщение за грешка е догадка.
Когато името идва от тунел
Локалното пренасочване на порт чупи проверката на идентичността по начин, който изненадва хората. Ако пренасочите локален порт към базата данни и се свържете с localhost, клиентът валидира сертификата срещу localhost, а за това име не е издаван сертификат. Връзката може да е напълно сигурна и проверката пак ще се провали, което означава, че проверката работи както трябва.
Има два честни отговора. Дайте на пренасочената крайна точка име, което се разрешава до адреса за обратна връзка и присъства в сертификата на сървъра, или използвайте името на хоста от край до край, за да провери клиентът истинската идентичност. Първото е удобно за разработчици и изисква работа по сертификатите; второто е по-лесно за обмисляне и често е правилната настройка по подразбиране за автоматизация. Изключването на проверката, за да работи пренасочването, изхвърля свойството, което сте се опитвали да добавите.
Приемането е три условия
Напишете приемния тест като три отделни твърдения: връзката е използвала предназначения маршрут, криптирането е било изисквано, а не предпочитано, и идентичността на сървъра е проверена срещу доверен материал. Зелена икона на VPN не установява нито едно от тях.
За GUI клиенти и за MariaDB проверявайте собствената документация на доставчика, вместо да предполагате, че изписването на флага се пренася. Документацията на MySQL за криптирани връзки обхваща разликите между режимите и изискването за разпространение на CA и е справката, която да проверите, преди да промените производствен низ за връзка.