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 без вредност бара внес, што ја чува тајната надвор од списокот на процеси и надвор од историјата на вашата обвивка. Тоа е мала навика со голема корист на споделени скокачки хостови, каде командната линија е видлива за други корисници.
Кога ова не успее, текстот на грешката ги разликува случаите подобро од интуицијата. Грешка со CA значи дека синџирот не се валидира и треба да погледнете кој CA го потпишал сертификатот на серверот. Грешка со име на хост значи дека синџирот е во ред, а името не се совпаѓа, што обично значи дека сте се поврзале со правилниот сервер под погрешно име, а не со погрешниот сервер.
Појавувањето на промпт не е доказ дека лозинката веќе е пренесена, а неуспешната врска не докажува дека ништо не излегло од клиентот. Ако реконструирате минат настан, идентификувајте го клиентот, неговата конфигурација, додатокот за автентикација и фазата што не успеа. Проценката на изложеноста од последната порака за грешка е погодување.
Кога името доаѓа од тунел
Локалното пренасочување на порта ја крши проверката на идентитетот на начин што ги изненадува луѓето. Ако пренасочите локална порта кон базата на податоци и се поврзете со localhost, клиентот го валидира сертификатот против localhost, а за тоа име не е издаден сертификат. Врската може да биде целосно безбедна и проверката сепак нема да успее, што е проверката што работи како што е наменета.
Постојат два чесни одговори. Дајте ѝ на пренасочената крајна точка име што се разрешува на loopback адресата и се појавува во сертификатот на серверот, или користете го името на хостот од почеток до крај за клиентот да го провери вистинскиот идентитет. Првото е погодно за развивачи и бара работа со сертификати; второто е полесно да се размислува и често е правилната стандардна вредност за автоматизација. Исклучувањето на проверката за пренасочувањето да работи ја фрла особината што се обидовте да ја додадете.
Прифаќањето е три услови
Напишете го тестот за прифаќање како три одделни тврдења: врската го користеше наменетиот пат, шифрирањето беше барано, а не преферирано, и идентитетот на серверот беше проверен против доверлив материјал. Зелена VPN икона не воспоставува ниту едно од нив.
За GUI клиенти и за MariaDB, проверете ја сопствената документација на продавачот наместо да претпоставите дека правописот на знамето се пренесува. Документацијата на MySQL за шифрирани врски ги покрива разликите меѓу режимите и барањето за дистрибуција на CA, и тоа е референцата што треба да се провери пред да се смени продукциска низа за врска.