Tunnel SSH dan TLS

Gunakan tab SSH kalau database hanya menerima koneksi dari dalam jaringan privat, dan tab SSL untuk mengenkripsi koneksi serta menentukan sertifikat server mana yang dipercaya. Keduanya ada di dialog koneksi, dan keduanya ikut dicek oleh Test sebelum kamu menyimpan.

Tunnel SSH

1. Buka dialog koneksi dan masuk ke tab SSH.
2. Centang Connect through an SSH tunnel.
3. Isi SSH host (bastion), SSH port (default 22) dan SSH user.
4. Di Authentication, pilih Private key atau Password.
5. Untuk key, arahkan Private key ke file key (default ~/.ssh/id_ed25519; key ed25519, RSA dan PEM bisa dipakai) lalu isi Key passphrase kalau key-nya memakai passphrase. Untuk password, isi SSH password.
6. Biarkan Local port berisi auto kecuali kamu butuh port tetap, lalu klik Test.

Di tab General, isi host database sebagaimana bastion melihatnya. Kalau database berjalan di bastion itu sendiri, isinya 127.0.0.1.

Selekta membuka session SSH sendiri dan meneruskan sebuah port di 127.0.0.1 pada Mac kamu ke database. Dengan auto, port yang sedang tidak dipakai dipilih setiap kali tunnel dibuka. Passphrase atau password SSH disimpan di macOS Keychain, terpisah dari password database. Kalau session SSH putus, misalnya setelah sleep atau ganti jaringan, session dibangun ulang di port lokal yang sama saat driver terhubung lagi, jadi reconnect tetap jalan tanpa membuka dialog.

Host key SSH

Selekta mencocokkan host key bastion dengan ~/.ssh/known_hosts, file yang sama dengan yang dipakai perintah ssh.

Key belum dikenal. Saat pertama kali terhubung ke sebuah bastion, tes berhenti sejenak di "opening tunnel" dan dialog Verify SSH host key menampilkan host, jenis key dan fingerprint SHA-256. Bandingkan fingerprint itu dengan yang diumumkan pemilik bastion, lalu klik Trust and connect. Key ditulis ke ~/.ssh/known_hosts setelah autentikasi berhasil, dan kamu hanya ditanya lagi kalau key-nya berubah. Cancel menghentikan tes; tidak ada yang dikirim ke host.

Key berubah. Kalau bastion menyodorkan key yang berbeda dari yang tersimpan, dialog SSH host key changed memblokir koneksi. Dialog ini menampilkan fingerprint yang tersimpan (beserta barisnya di ~/.ssh/known_hosts) di samping fingerprint yang disodorkan. Selekta tidak pernah langsung menerima key yang berubah. Kalau pemilik bastion memastikan key baru itu benar:

1. Klik Remove stored key… dan konfirmasi dengan Remove key.
2. Klik Test lagi.
3. Cocokkan fingerprint baru di dialog Verify SSH host key lalu klik Trust and connect.

OpenVPN

Tab VPN menghubungkan satu koneksi lewat OpenVPN. Client-nya berjalan di dalam Selekta: tidak perlu hak admin, dan route serta DNS di Mac kamu tidak diubah. Koneksi dan aplikasi lain tidak terpengaruh.

1. Centang Connect through OpenVPN.
2. Arahkan Profile ke file .ovpn dari admin VPN kamu. File yang dirujuk profil dibaca dari folder yang sama.
3. Isi VPN username dan VPN password kalau profil memintanya. Kosongkan username kalau profil hanya memakai sertifikat. Profil dengan auth-user-pass <file> juga bisa mengambilnya dari file tersebut.
4. Biarkan Local port berisi auto lalu klik Test.

Satu koneksi memakai tunnel SSH atau VPN, tidak keduanya. Direktif profil yang tidak diimplementasikan Selekta, seperti tls-crypt, pkcs12, compress, http-proxy atau dev tap, ditolak dengan pesan yang menyebut namanya, jadi kamu tidak pernah mendapat tunnel yang setengah jalan.

SSL mode

Tab SSL mengatur cara koneksi dienkripsi. Nama mode mengikuti istilah masing-masing engine.

• prefer / PREFERRED memakai TLS kalau server menawarkannya. require / REQUIRED mewajibkan TLS tetapi tidak memeriksa sertifikat.
• verify-ca / VERIFY_CA memeriksa rantai sertifikat. verify-full / VERIFY_IDENTITY juga memeriksa bahwa sertifikat cocok dengan nama host. Gunakan mode ini untuk server di luar mesinmu.
• Koneksi PostgreSQL dan MySQL baru default ke require (REQUIRED) untuk host remote dan prefer (PREFERRED) untuk localhost dan 127.0.0.1, yang sering tidak punya TLS. Mode yang kamu pilih sendiri, atau yang diatur oleh URL yang ditempel, tetap dipertahankan.
• SQL Server default ke Encrypt, trust server certificate, yang dibutuhkan server development dan server dengan sertifikat self-signed. Off tetap mengenkripsi login, tetapi query dan hasilnya dikirim tanpa enkripsi.

Dengan mode nonaktif ke host remote, tab ini memperingatkan bahwa lalu lintas dan password dikirim tanpa enkripsi. Koneksi SQLite tidak punya tab SSL.

Sertifikat dan TLS minimum

• CA certificate: file PEM untuk memverifikasi server. Kosongkan untuk memakai system trust store macOS.
• Client certificate dan Client key: opsional, untuk server yang mewajibkan autentikasi sertifikat (PostgreSQL dan MySQL).
• Minimum TLS: 1.2 (default) atau 1.3. Dengan 1.3, server yang hanya bisa TLS 1.2 gagal dites dengan pesan yang menyebut versi yang ditawarkannya.

Setelah tes berhasil, banner menampilkan versi TLS yang dinegosiasikan, misalnya TLS 1.3, atau no TLS.

Sertifikat yang tidak dipercaya dan pinning

Saat mode yang memverifikasi tidak bisa mempercayai sertifikat server, tes berhenti di TLS handshake, sebelum password apa pun dikirim, dan dialog Server certificate not trusted terbuka. Dialog ini menampilkan subject, issuer, tanggal kedaluwarsa, mode dan CA yang sedang dipakai, serta fingerprint SHA-256 sertifikat. Ada tiga pilihan:

• Cancel membiarkan semuanya seperti semula.
• Switch to verify-full with a CA file… (VERIFY_IDENTITY untuk MySQL, Encrypt and verify untuk SQL Server) memasang mode ketat dan membuka pemilih file untuk sertifikat CA. Ini solusi yang tepat kalau organisasimu punya CA sendiri.
• Trust this certificate for this connection mem-pin sertifikat itu persis. Tes dijalankan lagi, dan fingerprint SHA-256 disimpan bersama koneksi saat kamu klik Save.

Koneksi yang di-pin hanya menerima satu sertifikat itu. Saat sertifikat server diperbarui atau diganti, tes berhenti lagi dan menampilkan sertifikat yang baru, jadi sertifikat yang tertukar tidak pernah lolos diam-diam. Sertifikat yang sudah kedaluwarsa tidak bisa di-pin; dialog menandainya expired dan hanya menawarkan jalur CA.

Untuk PostgreSQL dan MySQL, Selekta menegakkan pin lewat relay kecil di 127.0.0.1 yang berbicara TLS ke server dan hanya menerima sertifikat yang di-pin. Untuk SQL Server, yang TLS-nya berjalan di dalam protokolnya sendiri, pin diperiksa lewat handshake terpisah tepat sebelum setiap koneksi.

Related

• Koneksi
• PostgreSQL
• MySQL dan MariaDB
• Pemecahan masalah