Hacker News new | past | comments | ask | show | jobs | submit login

Interesting project, I could see a use case for emerging markets where people don't have laptops. Maybe also include a local PG like https://supabase.com/blog/postgres-wasm for being able to play around with PG educationally with no required remote server?

For professional use cases, maybe if you're on call and need to access the DB over your phone (though I hope I'm never in that spot). Having documentation around network model - do you relay queries through your own backend - and the security model for data and credentials. Do you support any secure connection methods, like SSH tunnel, or does the PG need to be facing the public internet?




> Maybe also include a local PG like https://supabase.com/blog/postgres-wasm for being able to play around with PG educationally with no required remote server?

I did not know about wasm-postgres, thanks!

> Having documentation around network model - do you relay queries through your own backend - and the security model for data and credentials. Do you support any secure connection methods, like SSH tunnel, or does the PG need to be facing the public internet?

There's no backend, the app opens a connection directly to the database. Credentials are stored on-device. No data will ever be shipped to a third-party without user consent, and I will never change this. (This is a large part of why I haven't put in any "AI" features yet.)

The app currently does not support SSH tunneling. This is something I will be working on soon.

Also fair point on the documentation. There's currently 0 docs around the app, and I'm not proud of that.


Postgres has secure connection methods, including client and server TLS cert authentication.

You could also hide it behind tailscale/nebula or some other VPN thing.


I’m curious how secure is TLS client authentication if the database is exposed to the internet?


What are you talking about?

public key cryptography is well understood and used everywhere: HTTPS, SSH, Signal, etc.

See: https://en.wikipedia.org/wiki/Public-key_cryptography

In postgres specifically: https://www.postgresql.org/docs/16/ssl-tcp.html and https://www.postgresql.org/docs/16/runtime-config-connection...

You can enforce TLSv1.3 on all network connections using `ssl_min_protocol_version`(postgres.conf) and `hostssl`(in pg_hba.conf)

This puts you ahead of most web servers which often still allow TLSv1.1.

You can make Postgres secure or not, your call. Just like with everything else.


I would note that, although obviously the confidentiality in TLS is based on public key cryptography, authentication by mTLS doesn’t reach the cryptography part.

The process starts with a client and server hello. Then the server sends its certificate to the client, and the client sends its certificate to the server. The server verifies that the client’s certificate is signed by a certificate authority in its trust store. That’s the authentication part. The client’s private key is not used.

The confidentiality comes next if authentication is successful.

I asked because X509 certificates are complex and difficult to securely parse. Also mTLS is rarely used.


PostgreSQL uses OpenSSL for TLS: https://www.postgresql.org/docs/devel/install-requirements.h...

> The client’s private key is not used.

This whole section is incorrect. It's called mutual TLS. The client's private key is used to prove to the server it has the private key for the public key it's handing to the server. Just like the server has to prove to the client, it has the private key to the public cert it hands out.

Otherwise there is no authentication going on at all.

See the RFC: https://www.rfc-editor.org/rfc/rfc8446 If you are unfamiliar with RFC's, see Section 4.4 and Appendix E.1, which talk about client auth and the handshake respectively.

> I asked because X509 certificates are complex and difficult to securely parse

Yes, but that's why PG relies on OpenSSL to do that work for them. It's widely deployed, even using client certificates. X.509 is used with client certificates by at least 3.5M active personnel with the US DoD via their Common Access Card, as one widely used example.

> Also mTLS is rarely used.

Mutual TLS or client auth is not often used in the browser context, because the browsers have miserable UX around it. I wish that would change, but I'm one of the very few.

It's regularly used outside of the browser context though. Lots of B2B and Service Oriented Architectures use it.


Yes, sorry the private is indeed used in mTLS.

Without that there is still authentication: clients who don’t presents a certificate signed by CA are refused. A weaker form of authentication is who ever presents a signed certificate connects, regardless of whether they hold the private key or not. In practice, these two are packed into a p12 certificate anyways, at least browsers.

Interesting that defense industry uses mTLS. It’s a pitty because the UX could be good: no need to route the entire traffic by a VPN. Simply have a certificate in the browser and the user will have access with no further action or setup.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: