Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

security: missing support for GSS encryption (not authentication) #52184

Open
knz opened this issue Jul 31, 2020 · 9 comments
Open

security: missing support for GSS encryption (not authentication) #52184

knz opened this issue Jul 31, 2020 · 9 comments
Labels
A-security A-server-networking Pertains to network addressing,routing,initialization C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) T-server-and-security DB Server & Security X-anchored-telemetry The issue number is anchored by telemetry references.
Projects
DB Server & Security SQL Features (Deprecated - use SQL Ex...

Comments

@knz
Copy link
Contributor

knz commented Jul 31, 2020 •
edited by cockroach-jira-scripts

GSSAPI defines security primitives at multiple levels. It is really a competing stack to TLS.

In PostgreSQL, both GSSAPI client authentication and transport encryption are supported separately.

The "best practice" for deployment in a GSS environment is to use them hand-in-hand.

In CockroachDB, we only support GSSAPI client authentication, but not GSSAPI transport encryption.

Here's the combination of features:

Transport encryption Endpoint authentication Supported by pg Supported by crdb
TLS TLS yes (recommended) yes (recommended)
GSS GSS yes (recommended) no
TLS TLS+GSS yes (not recommended) yes
GSS TLS not supported N/A

Why this matters:

  • transport encryption is important to protect the connection against sniffing attacks.
  • however this protection is only active under under the guarantee there was no MITM attack, i.e. it's only valid after authentication phase, when both sides of the connection have verified the identity of the other side.
  • therefore, encryption only "works" if the client can verify the server's identity
  • most client drivers don't know how to verify the server identity using GSSAPI unless GSSAPI transport encryption is enabled
  • therefore, TLS encryption requires validation of the TLS server certificate in any case
  • therefore, GSS authn over TLS enc requires a setup to both provides GSS tokens and TLS server certs to client apps, which is more work and more complex to operate than a pure-GSS, real single-sign-on infrastructure (what PostgreSQL supports).

So it's likely that CockroachDB would be better off supporting GSSAPI transport encryption (and the hostgssenc directives in the HBA config) in addition to TLS, to ease deployments with kerberos infrastructures.

Jira issue: CRDB-3975
@knz knz added C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) A-security labels Jul 31, 2020
@knz knz added this to To do in DB Server & Security via automation Jul 31, 2020
@knz
Copy link
Contributor Author

knz commented Jul 31, 2020

@thtruo @aaron-crl @dbist - could you review this and provide feedback about how much customer ask there is for this, and/or how much product value we would create by investing into it.

@dbist
Copy link
Contributor

dbist commented Jul 31, 2020

@BramGruneir any context from your customerbase you can add?

@dbist
Copy link
Contributor

dbist commented Jul 31, 2020

In PCI compliant environments this would be critical though having this capability with TLS makes it hard to justify one over the other. I think consolidating on TLS or GSS for both authN and transport encryption is a welcome addition but whether it is a high priority ask I won't know until customers ask for it.

@aaron-crl
Copy link

I'm not sure how much of a concern: "most client drivers don't know how to verify the server identity using GSSAPI unless GSSAPI transport encryption is enabled" is in practice. Let's see how much of a customer demand there is for this before delving too deep here.

There are other ways to solve the problem in a PCI environment that do not require application support for GSS. Depending on configuration, other transport level security mechanics are possible including things like IPSec at the OS level where the tunnel is negotiated using GSS primitives.

@dbist
Copy link
Contributor

dbist commented Aug 17, 2020 •
edited

I evaluated #3 by connecting to a kerberized cluster with root user using cert and a kerberos principal as well. Both showed connection hostssl based on the behavior in the following doc. So given we support it but not necessary feel it is seamless, what should the next step be? So far I have not heard of any customer asking for GSS encryption in the same conversation with Cockroach but I know of one potential prospect that may care?

I200817 19:06:12.898466 2878 sql/pgwire/conn.go:226  [n1,client=172.28.1.7:56844,hostssl,user=sqlalchemy] 14 session terminated; duration: 240.3243ms

sqlalchemy is a kerberos principal.

@knz knz moved this from To do to Cold storage in DB Server & Security Aug 24, 2020
@bdarnell
Copy link
Member

When a user attempts to use GSS encryption, the server just logs an inscrutable message: unknown protocol version 80877104. We should add a better error message in this switch and get telemetry on attempted usage.

@knz knz added the X-anchored-telemetry The issue number is anchored by telemetry references. label Apr 15, 2021
@knz knz mentioned this issue Apr 15, 2021
Merged
@knz
Copy link
Contributor Author

knz commented Apr 15, 2021

adding telemetry for this in #63734

knz added a commit to knz/cockroach that referenced this issue Apr 15, 2021
@knz
pgwire: report telemetry for GSS encryption
b5e54e4 
GSS encryption is not yet supported: cockroachdb#52184

This patch adds telemetry for attempted uses and a better message in
clients.

Release note: None
craig bot pushed a commit that referenced this issue Apr 15, 2021
@darinpp @knz
Merge #63616 #63734
b225345 
63616: ccl/sqlproxyccl: adding cert manager to allow cert rotation on SIGHUP r=darinpp a=darinpp

Previously the proxy didn't process SIGHUP and wasn't reloading the
certificates when SIGHUP is sent to the process.
This is a problem as rotating certificates requires restart and
this desirable.
This PR adds a certification manager that monitors for SIGHUP and
reloads the managed certificates automatically. A similar code exists
for the cockroach executable but the code there is very specific for the
set of certificates that cockroach db uses. The one provided in this PR
is generic and can be used as a building block in any application. The
code that utilized the cert manager is not part of this PR and will be
committed with the changes in the main proxy code. This is in separate PR
to make the review easier.

We currently have a cert manager that cockroachdb used in `pkg/security`.
This PR can be used as a base of the existing code. The first step of
refactoring the existing code is pulling aside a generic version of a
cert manager that can do part of what `pkg/security` needs and can also
do what proxy needs. So this PR does this. The second step however is
to change the existing code to create a instantiate the generic cert
manager, put in it the set of certs applicable to cockroach db and
remove the current signal handler. This can happen in another PR.

Release note: None

63734: pgwire: report telemetry for GSS encryption r=bdarnell a=knz

GSS encryption is not yet supported: #52184

This patch adds telemetry for attempted uses and a better message in
clients.

Release note: None

Co-authored-by: Darin Peshev <darinp@gmail.com>
Co-authored-by: Raphael 'kena' Poss <knz@thaumogen.net>
knz added a commit to knz/cockroach that referenced this issue May 18, 2021
@knz
pgwire: report telemetry for GSS encryption
11a3c86 
GSS encryption is not yet supported: cockroachdb#52184

This patch adds telemetry for attempted uses and a better message in
clients.

Release note: None
@jlinder jlinder added the T-server-and-security DB Server & Security label Jun 16, 2021
@knz knz added the A-server-networking Pertains to network addressing,routing,initialization label Jul 29, 2021
@knz knz mentioned this issue Apr 14, 2022
Closed
@data-matt
Copy link

@knz, I know this is the "cold storage", but I would like to check.

  1. Would this cover GSS transport encryption for the client?
  2. With both of authN and encryption, at that point we could kerberos authN cockroach cli in GSS based environments?

Thanks

@knz
Copy link
Contributor Author

knz commented Aug 30, 2022

crdb CLI already can use kerberos authentication (albeit over TLS). We even test it in CI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-security A-server-networking Pertains to network addressing,routing,initialization C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) T-server-and-security DB Server & Security X-anchored-telemetry The issue number is anchored by telemetry references.
Projects
DB Server & Security
  
Cold storage
SQL Features (Deprecated - use SQL Ex...
  
Backlog
Milestone
No milestone
Development

No branches or pull requests
6 participants
@bdarnell @jlinder @dbist @knz @aaron-crl @data-matt