MySQL преко VPN-а: проверите сервер, а не само шифровање

Шифровање ка погрешном хосту и даље је погрешно. Упоредите вредности ssl-mode, затим покрените везу која именује жељени сервер и то доказује.

Чувате везу ка 10.20.4.15, VPN пада, а клијент се ипак повезује. То нису добре вести. Приватна адреса је место унутар било ког контекста рутирања у ком се налазите, и многе мреже користе исте опсеге. Клијент је стигао до MySQL сервера, само можда не до вашег.

Исправка има две половине, и само једна од њих је о мрежи. Држите везу на предвиђеној путањи и натерајте клијента да провери сервер са којим разговара. Прва половина је тамо где VPN помаже; друга мора да се конфигурише.

Шифровано ка чему, тачно?

TLS штити разговор од свакога у средини и не говори ништа о томе ким се крајња тачка представља, осим ако клијент то не провери. Сертификат који се валидира код поузданог органа доказује да сертификат долази од тог органа. Не доказује да је сертификат издат за име хоста које сте желели да достигнете, и то су различита питања.

Ово није теоријска празнина. Captive портали, грешке са погрешним VRF-ом и планови адреса који се преклапају сви стварају сервер који је потпуно спреман да преговара TLS са вама. Ако клијент захтева само шифровање, сесија је приватна и усмерена на погрешну базу података.

Дакле, релевантно питање није да ли је веза шифрована, већ да ли је шифрована ка идентитету који сте намеравали. У MySQL клијенту та разлика живи потпуно у подешавању ssl-mode.

Пет вредности ssl-mode у пракси

Постоји пет вредности, и само једна од њих одговара на питање овог приручника. Табела наводи шта свака заиста гарантује, а не шта њено име сугерише.

ModeWhat it guarantees
DISABLEDNo TLS at all; everything on the wire is readable
PREFERREDTries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement
REQUIREDRefuses to connect without TLS, and does not validate the certificate
VERIFY_CAValidates the server certificate against the configured CA and does not check the hostname
VERIFY_IDENTITYValidates 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, и то је референца коју треба проверити пре него што промените производни низ везе.

Повезани чланци