Šifrování pg_dump pomocí OpenSSL

[czechsys]

hm, tohle je dost velká prasárna, nikdy jsem se s tím zatím nesetkal, je ale pravda, že velké archivy s openssl nešifruji snad nikde, všude je gpg či jiný nástroj či formát. Dobré vědět!

Jake jine nastroje krome gpg pouzivas?

Přidej si tam ty checksumy, hned by ti to spadlo na validaci, protože rozbalený šifrovaný archiv by měl jiný checksum než originál. Jak psal Filip, checksum si ukládej vedle do souboru. Vyhneš se všem těmhle hidden truncate problémům nebo třeba OOM chybě při šifrování.

Jak s temi checksumy? Protoze si neumim moc predstavit, jak je pouzit, pokud pouziju roury. Protoze bez vyuziti rour bych nejdrive ulozil na disk komprimovany dump (=X write iops, size Y), pak checksum, pak vytvorit sifrak (+ X read, +X write, +Y size), pak otestovat?? desifrovanim...no vychazi mi z toho mnohem vetsi narocnost na diskovou kapacitu a vykon nez u rour. Asi mi neco uchazi...

Jinak obecne, ma nekdo zkusenosti krome gpg s https://github.com/FiloSottile/age? Vypada to presne na ten jednoduchy use-case, co mam, bez potreby se namahat s keystore apod...Navic to je v debian repozitari a pro starsi servery je k dispozici binarka na githubu...

[Reklama]

[NCC1701E]

A co zkusit misto -in to pri desifrovani taky brat jako stream?

Tak otestovano s pridanym parametrem -stream:

Kód: [Vybrat]

#cat ./db3_15.05.24-00_00.sql.gz | openssl smime -encrypt -aes256 -binary -stream -outform DEM -out ./encrypted.sql.gz.ssl pgdump_backup.pem
-rw-r--r-- 1 root   root     7910422089 May 15 00:28 db3_15.05.24-00_00.sql.gz
-rw-r--r-- 1 root   root     7918147866 May 15 09:36 encrypted.sql.gz.ssl


Kód: [Vybrat]

#openssl smime -decrypt -in ./encrypted.sql.gz.ssl -binary -inform DEM -inkey ./pgdump_backup_key.pem -out ./decrypted.sql.gz
Error reading S/MIME message
4077734DF87F0000:error:038C0100:memory buffer routines:BUF_MEM_grow_clean:malloc failure:../crypto/buffer/buffer.c:128:
4077734DF87F0000:error:068C0100:asn1 encoding routines:asn1_d2i_read_bio:malloc failure:../crypto/asn1/a_d2i_fp.c:209:

#openssl smime -decrypt -in ./encrypted.sql.gz.ssl -binary -stream -inform DEM -inkey ./pgdump_backup_key.pem -out ./decrypted.sql.gz
Error reading S/MIME message
40073BBB2D7F0000:error:038C0100:memory buffer routines:BUF_MEM_grow_clean:malloc failure:../crypto/buffer/buffer.c:128:
40073BBB2D7F0000:error:068C0100:asn1 encoding routines:asn1_d2i_read_bio:malloc failure:../crypto/asn1/a_d2i_fp.c:209:

#free -h
               total        used        free      shared  buff/cache   available
Mem:            47Gi        13Gi       3.2Gi        11Gi        42Gi        33Gi
Swap:          2.7Gi       1.3Gi       1.4Gi

To je sranda. Tak zpatky na zacatek nekam do praveku...

[_Tomáš_]

hm, tohle je dost velká prasárna, nikdy jsem se s tím zatím nesetkal, je ale pravda, že velké archivy s openssl nešifruji snad nikde, všude je gpg či jiný nástroj či formát. Dobré vědět!

Jake jine nastroje krome gpg pouzivas?

zip , jinak sám třeba age (ano, je to poslehlivý zajímavý projekt jak šifrovat, stojí za ním Filippo Valsorda, což je osoba s mnoha lety zkušeností na poli kryptografie, dělal v cloudlflare, měl na starosti šifrování v go), na freebsd enigma/crypt. U klientů často enterprise grade nástroje. Openssl jsem si vůbec neoblíbil.

Přidej si tam ty checksumy, hned by ti to spadlo na validaci, protože rozbalený šifrovaný archiv by měl jiný checksum než originál. Jak psal Filip, checksum si ukládej vedle do souboru. Vyhneš se všem těmhle hidden truncate problémům nebo třeba OOM chybě při šifrování.

Jak s temi checksumy? Protoze si neumim moc predstavit, jak je pouzit, pokud pouziju roury. Protoze bez vyuziti rour bych nejdrive ulozil na disk komprimovany dump (=X write iops, size Y), pak checksum, pak vytvorit sifrak (+ X read, +X write, +Y size), pak otestovat?? desifrovanim...no vychazi mi z toho mnohem vetsi narocnost na diskovou kapacitu a vykon nez u rour. Asi mi neco uchazi...

No, nejlepší je to prostě uložit bokem, udělat checksum a pak další operace. Nebudeš muset totiž řešit situaci, kdy ti procesy spadnou a zůstane ti tam poloviční archiv. Když to nechceš opravdu řešit přes roury, tak aspoň s pipefail, checksum můžeš vypočít streamovaně přes tee, dešifrování a druhému přečtení se nevyhneš, to je ale logické.

Kód: [Vybrat]

# důležité je nastavit pipefail pro bash
set -euo pipefail


# lehce můžeš upravit tvoje roury
/usr/bin/pg_dump --create --exclude-schema=XX --exclude-schema=XY "$line"| tee >(sha256sum > "${PDIR}/${line}_${OFP}.sha256") | gzip -c | openssl smime...

# pak backup dešifrovat a přečíst, tomu se stejně tak nevyhneš
backup_checksum="$(openssl smime -decrypt ... | gzip -d | sha256sum)"

# můžeš provést kontrolu, v obou případěch je filename "-", takže můžeme přímo porovnat
if [[ "$(cat "${PDIR}/${line}_${OFP}.sha256")" != "$backup_checksum" ]]; then
    >&2 echo "checksum mismatch for ${PDIR}/${line}_${OFP}"
    exit 1
fi


[_Tomáš_]

ten checksum soubor poté zálohuj i s backem, poslouží ti před obnovou ke kontrole integrity. Podle způsobu kam ten backup  pak dáváš je možné udělat i checksum šifrovaného archivu, abys nemusel pro kontrolu dělat pokaždé dešifrování. Zejména u velkých soborů či při jejich splitování může nastat spousta nečekaných chyb, viz teď i to openssl.

[Filip Jirsák]

Jak s temi checksumy? Protoze si neumim moc predstavit, jak je pouzit, pokud pouziju roury. Protoze bez vyuziti rour bych nejdrive ulozil na disk komprimovany dump (=X write iops, size Y), pak checksum, pak vytvorit sifrak (+ X read, +X write, +Y size), pak otestovat?? desifrovanim...no vychazi mi z toho mnohem vetsi narocnost na diskovou kapacitu a vykon nez u rour. Asi mi neco uchazi...

Se standardními utilitami to bez toho uložení do souboru asi nepůjde. Je pravda, že by bylo fajn, kdyby ty *sum utility uměly fungovat jako průtokáč – četly by ze standardního vstupu, kopírovaly obsah na standardní výstup a bokem počítaly hash, který by zapsaly do souboru. Asi je to příležitost potrénovat Rust a takovou utilitu napsat :-)

[Reklama]

[petersveter]

inak pg dump podporuje kompresiu, nie je nutne to tahat cez gzip.

[_Tomáš_]

ten checksum soubor poté zálohuj i s backem, poslouží ti před obnovou ke kontrole integrity. Podle způsobu kam ten backup  pak dáváš je možné udělat i checksum šifrovaného archivu, abys nemusel pro kontrolu dělat pokaždé dešifrování. Zejména u velkých soborů či při jejich splitování může nastat spousta nečekaných chyb, viz teď i to openssl.

proč bys dělal v rustu nástroj na něco, co jde dokonce napsat i v posixu? V bashi to je daleko čitelnější a srovnatelné se specializovaným nástrojem.

Kód: [Vybrat]

mkfifo checksum.fifo
sha256sum < checksum.fifo > "${PDIR}/${line}_${OFP}.sha256" &

/usr/bin/pg_dump --create --exclude-schema=XX --exclude-schema=XY "$line"| tee checksum.fifo | gzip -c | openssl smime...
rm checksum.fifo

# pak backup dešifrovat a přečíst, tomu se stejně tak nevyhneš
backup_checksum="$(openssl smime -decrypt ... | gzip -d | sha256sum)"

# můžeš provést kontrolu, v obou případěch je filename "-", takže můžeme přímo porovnat
if [ "$(cat "${PDIR}/${line}_${OFP}.sha256")" != "$backup_checksum" ]; then
    >&2 echo "checksum mismatch for ${PDIR}/${line}_${OFP}"
    exit 1
fi


[Filip Jirsák]

Protože v Rustu je napsaná knihovna Blake3 a utilita b3sum, takže udělat tu utility průchozí by byla úprava na pár řádek kódu. A bylo by to jednodušší na použití, daleko rychlejší a efektivnější než tahle shellová opičárna.

[_Tomáš_]

Protože v Rustu je napsaná knihovna Blake3 a utilita b3sum, takže udělat tu utility průchozí by byla úprava na pár řádek kódu. A bylo by to jednodušší na použití, daleko rychlejší a efektivnější než tahle shellová opičárna.

očividně nikdo takový PR neposlal, asi to nikdo nepotřebuje, nevím, jestli jsi viděl jejich kód, díky rozdělení na více vláken a asynchronnímu počítání by to mohlo být na více než pár řádků kódu. Mimochodem, openbsd/freebsd mají přepínač -p, na posledním řádku výstupu je poté vypočítaný checksum.