The default cipher suites used by Go include a number of ciphers that
have known weaknesses. In addition to leaving users open to these
weaknesses, the inclusion of these weaker ciphers causes problems with
various automated scanning tools.
This PR disables the CBC-mode, RC4, and 3DES ciphers included in the
Go standard library by passing an explicit cipher suite list.
The ciphers included here are more line with those recommended by
Mozilla for "Intermediate" compatibility. [0]
*Performance Implications*
The Go standard library does capability-based cipher ordering,
preferring AES ciphers if the underlying hardware has AES specific
instructions. [1] Since all of the relevant code is internal modules,
to do the same thing ourselves would require duplicating that
code. Here, I've placed AES based ciphers first.
*Compatibility Implications*
This does reduce the number of clients who will be able to communicate
with dex.
[0] https://ssl-config.mozilla.org/#server=nginx&server-version=1.17.0&config=intermediate&hsts=false&ocsp=false
[1] a8c2e5c6ad/src/crypto/tls/common.go (L1091)
Signed-off-by: Steven Danna <steve@chef.io>
Some environments are subject to strict rules about the permitted TLS
protocol verion and available ciphers. Setting TLSv1.2 as the minimum
version ensures we do not use weaker protocols. We've opted against
making this configurable given the age of TLSv1.2 and the increasing
push to deprecate TLSv1.1 and older.
The PreferServerCipherSuites setting is also commonly flagged by SSL
quality scanning tools. Since Go provides a relatively modern set of
default ciphers by default, defaulting this to true is unlikely to
make much practical difference.
Signed-off-by: Steven Danna <steve@chef.io>
- adapted TestUnmarshalConfig to ensure the fields are read in
- added a test to see that at least MaxOpenConns works:
- this is only exposed through (*db).Stats() in go 1.11, so this test
has a build tag
- the other two configurables can't be read back, so we've got to
trust that the mechanism works given the one instance that's tested..
Signed-off-by: Stephan Renatus <srenatus@chef.io>
This patch adds etcd storage implementation. This should be useful in
environments where
- we dont want to depends on a separate, hard to maintain SQL cluster
- we dont want to incur the overhead of talking to kubernetes apiservers
- kubernetes is not available yet, or if kubernetes depends on dex
to perform authentication and the operator would like to remove any
circular dependency if possible.
Signed-off-by: zhuguihua <zhuguihua@cmss.chinamobile.com>
Change storace to storage in cmd/dex/config.go,
change userSearch to groupSearch in connector/ldap/ldap.go
This PR reworks the web layout so static files can be provided and
a "themes" directory to allow a certain degree of control over logos,
styles, etc.
This PR does NOT add general support for frontend customization,
only enough to allow us to start exploring theming internally.
The dex binary also must now be run from the root directory since
templates are no longer "compiled into" the binary.
The docker image has been updated with frontend assets.
Bcrypt'd hashes have "$" characters in them. This means that #667
(accepting actually bcrypted values) combined with #627 (expanding
config with environment variables) broke the example config.
For now, allow storages and connectors to expand their configs from
the environment, but don't do this anywhere else.
ghodss/yaml converts from YAML to JSON before attempting to unmarshal.
This allows us to:
* Get the correct behavor when decoding base64'd []byte slices.
* Use *json.RawMessage.
* Not have to support extravagant YAML features.
* Let our structs use `json:` tags
Allow users to define config values which are read form environemnt
variables. Helpful for sensitive variables such as OAuth2 client IDs
or LDAP credentials.
Some OpenID Connect providers, notably Google, don't follow the spec
and allow refresh tokens to be requested with the "offline_access"
scope. Try to determine which we're talking to by checking the
supported_scopes listed by the provider discovery.
Since we don't have a good strategy which takes a username and password
add a mock connector which implementes PasswordConnector so we can
develop the frontend screens.
It's not clear that the best way to manage clients is through a
gRPC based command line tool. For example we may explore an admin
dashboard and enable bootstrapping through static clients.
For now use static clients while we hold off on a more concrete
proposal.
