Closed ad6025b closed 1 week ago
Interesting. Server-side we do explicitly support TLS 1.2. Specifically, we support these ciphersuites:
// TLS1.3 suites
TLS13_AES_256_GCM_SHA384
TLS13_AES_128_GCM_SHA256
TLS13_CHACHA20_POLY1305_SHA256
// TLS1.2 suites
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
I'll take a look into why the serverless driver seemingly only supports 1.3 only.
Seems to be a limitation of @jawj's https://github.com/jawj/subtls which only supports TLS 1.3.
George, do you think we could use the platform TLS as a fallback option? I imagine subtls is only useful for the pipelined TLS websocket flow?
Alternatively, reckon we could add TLS 1.2 to subtls? TLS 1.2 is quite a bit more complex than 1.3 though IIRC so that might be a lot more effort.
@conradludgate That blog post is a bit out of date, and really the only reason to use subtls now is if you're running your own WebSocket<->TCP proxy for a standard (non-Neon) Postgres server, and this server only accepts encrypted connections, and you specifically bring in subtls in an attempt to encrypt your Postgres traffic.
(This is not recommended, because subtls is a POC with a big 'NOT READY FOR USE IN PRODUCTION' sign on it, and you're likely encrypting your connection twice over. But it's not unsafe as long as your WebSocket<->TCP proxy is accessed over https on the WebSocket side and the hop between the proxy and the database is on a private network).
So I'd be quite surprised if this were actually the issue here ...
@jawj @conradludgate to be clear, its the prisma client side tooling step that is failing. => as per you neon/prisma guidance: https://neon.tech/docs/guides/prisma-migrations ==> it is unable to apply the prisma migrate/sync schema step because it fails with
P1011: Error opening a TLS connection: The message received was unexpected or badly formatted. (os error -2146893018)
The TLS handshake is failing when it connects to neon, and tries to sync the schema for neondb
==> The root cause, is Prisma client tooling is connecting using TLS v1.2, but the neon server ONLY allows TLS 1.3 connections.
==> Prisma client cannot use TLS 1.3 yet (see the links at the top for more context)
Hey @ad6025b, Alberto from @prisma here.
I’ve attempted reproducing this issue with Prisma 5.19.1, and here's what I’ve got:
prisma migrate dev
, prisma db pull
and other schema migration commands work fine for me.I've run these test scenarios on both old and brand-new Neon test projects.
I’ve also tried tweaking the connection URL parameters: even ?sslmode=verify-full&ssl_min_protocol_version=TLSv1.3
works for me.
Can you please share more details of your setup, so we can continue the investigation on our side? More specifically:
aws.neon.tech/{database-name}?...
generator
and datasource
blocks from your schema.prisma
?Thanks!
@jkomyno thanks for looking into this. Im using a new simple project based on your neon/prisma guidance: https://neon.tech/docs/guides/prisma-migrations
here is my system spec:
`generator client { provider = "prisma-client-js" }
datasource db { provider = "postgresql" url = env("DATABASE_URL") }
model Author { id Int @id @default(autoincrement()) name String bio String? createdAt DateTime @default(now()) @map("created_at") books Book[]
@@map("authors") }
model Book { id Int @id @default(autoincrement()) title String authorId Int @map("author_id") createdAt DateTime @default(now()) @map("created_at") author Author @relation(fields: [authorId], references: [id])
@@map("books") } `
@jkomyno the connection string ending is:
postgresql://XXX@XXX.us-east-2.aws.neon.tech/XXXdbb?sslmode=require
BTW, i can connect to the neondb via a sql client successfully. (I use the JetBrain's DataGrip SQL client)
@jkomyno BTW, some other user had similar issues: https://github.com/prisma/prisma/issues/23675
He had similar specs : ==> im thinking this is a windows issue.
Environment & setup OS: Windows Database: PostgreSQL Node.js version: 20
@jkomyno BTW, some other user had similar issues: prisma/prisma#23675
He had similar specs : ==> im thinking this is a windows issue.
Environment & setup OS: Windows Database: PostgreSQL Node.js version: 20
Thanks for the additional details. Do you have WSL2 (Windows Subsystem for Linux) installed on Windows? If you were able to run Prisma migrations in there but not in the current setup, we could tell for sure that this issue is precisely tied to the Windows OS. Could you please give it a try and report back?
@jkomyno yes. using WSL2 the command works successfully.
@jkomyno i found root cause. its a windows 10 TLS 1.2 issue. The fix for this is here: ttps://www.electronicshub.org/a-fatal-error-occurred-while-creating-a-tls-client-credential-fix/
All good. my problem is fixed. thank you for your help!!!
Steps to reproduce
Install Prisma, and run the command [ npx prisma migrate dev --name dbinit ]. This command errors because Prisma ONLY support TLS v1.2. The error is:
P1011: Error opening a TLS connection: The message received was unexpected or badly formatted. (os error -2146893018)
for context:
Expected result
The command [ npx prisma migrate dev --name dbinit ] should work to sync prisma with neon db.
Actual result
TLS handshake error because Prisma is unable to connect with Neon db using TLS v1.3. (Prisma only supports TLS v1.2
Is there a workaround to force a TLS v1.2 connection? (Amazon RDS Aurora PostgreSQL allows selecting TLS v1.2 or TLS v1.3)?
Environment
Logs, links