| Age | Commit message (Collapse) | Author |
|---|
|
Fixes golang/go#61537
Change-Id: If3478121e3ae445391e3faeceeb889d75e9e3214
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/531935
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Nicola Murino <nicola.murino@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
|
|
When an error is returned by a user defined host key callback,
it is now possible to handle it using standard Go mechanisms
such as errors.Is or errors.As.
Fixes golang/go#61309
Change-Id: I4269c5f8eacd8e7e8d85070ad249f0e27777b15f
GitHub-Last-Rev: d2a34d5c8225d6aaaee287ce3ea8b218fbe210d4
GitHub-Pull-Request: golang/crypto#266
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/508876
Run-TryBot: Nicola Murino <nicola.murino@gmail.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Muhammad Shulhan <m.shulhan@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Nicola Murino <nicola.murino@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Tighter validation could cause backwards incompatibility issues, eg
configurations with valid and invalid MACs, KEXs, ciphers currently work
if a supported algorithm is negotiated and that's also the scenario of
removing support for an existing algorithm.
Fixes golang/go#39397
Change-Id: If90253ba89e1d8f732cc1e1c3d24fe0a1e2dac71
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/512175
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
RFC 8332, Section 2 sets up two overlapping namespaces: public key
formats and public key algorithms.
* The formats are what we currently have KeyAlgo constants for, and they
appear in PublicKey.Type.
* The algorithms are the set of both KeyAlgo and SigAlgo constants, and
they appear in Signature.Format (amongst other places).
This is incoherent, because that means Signature.Format can be both a
KeyAlgo (like KeyAlgoECDSA256) or a SigAlgo (like SigAlgoRSASHA2256).
One solution would be to duplicate all the KeyAlgo constants into the
SigAlgo namespace, but that would be confusing because applications are
currently using KeyAlgos where they'd be supposed to use the new
SigAlgos (while we can't deprecate the KeyAlgos because they are still
necessary for the PublicKey.Type namespace).
Instead, drop the separate namespaces, and use KeyAlgos throughout.
There are simply some KeyAlgos that can't be a PublicKey.Type.
Take the opportunity to fix the stuttering SHA22565/SHA2512 names. It's
totally ok to call those hashes SHA-256 and SHA-512 without the family
infix.
For golang/go#49952
Change-Id: Ia1fce3912a7e60aa70a88f75ed311be331fd19d5
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/392354
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
This change adds support for RSA SHA-2 based signatures for host keys and certificates. It also switches the default certificate signature algorithm for RSA to use SHA-512. This is implemented by treating ssh.Signer specially when the key type is `ssh-rsa` by also allowing SHA-256 and SHA-512 signatures.
Fixes golang/go#37278
Change-Id: I2ee1ac4ae4c9c1de441a2d6cf1e806357ef18910
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/220037
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
|
|
Fix golang/go#45249
Change-Id: I27ef2976586ad481d832c6e46695a91f1bb50373
GitHub-Last-Rev: 9f631b80925719a0fb77576f7983cd7c8d0b5056
GitHub-Pull-Request: golang/crypto#180
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/304990
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
Fixes golang/go#23194
During SSH Protocol Version Exchange, a client may send metadata lines
prior to sending the SSH version string. To conform to the RFC, all SSH
implementations must support this (minimally, clients can ignore the
metadata lines).
For example, this is valid:
some-metadata
SSH-2.0-OpenSSH
The current Go implementation takes the first line it sees as
the version string (in this case, some-metadata). Then, it uses
the next line (SSH-2.0-OpenSSH) as part of key exchange, which
is guaranteed to fail.
Unfortunately, this SSH feature is used by some vendors and is part
of the official RFC: https://tools.ietf.org/html/rfc4253#section-4.2
Change-Id: I7be61700a07756353875bf43aad09a580ba533ff
Reviewed-on: https://go-review.googlesource.com/86675
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Only show the SSH banner once, even if the client attempts
authentication with the "none" type and resets the authentication
attempts.
Change-Id: I1a7aacb50abf00233ed4d06c60808aaf51a9d7be
Reviewed-on: https://go-review.googlesource.com/78544
Run-TryBot: Sam Whited <sam@samwhited.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
|
|
According to RFC 4252 section 5.4, the banner is sent between the
ssh-connection request and responding to user authentication.
Original support for server sending banner by joshua stein <jcs@jcs.org>
Fixes golang/go#19567
Change-Id: I729b3c8e5fd2c0068609d1590b61e92f40d87ea4
Reviewed-on: https://go-review.googlesource.com/71790
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
|
|
This reverts commit ed5229da99e3a6df35c756cd64b6982d19505d86.
Reason for revert: missing language tag in banner message breaks auth against other implementations.
Change-Id: I18ac5b3fe3b4693688b82ff4b0db02dab739c45b
Reviewed-on: https://go-review.googlesource.com/72381
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
According to RFC 4252 section 5.4, the banner is sent between the
ssh-connection request and responding to user authentication.
Original support for server sending banner by joshua stein <jcs@jcs.org>
Fixes golang/go#19567
Change-Id: I68944a7f4711c0623759f6a59023e8e45a8781aa
Reviewed-on: https://go-review.googlesource.com/65271
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
|
|
Change-Id: I92c3916b0b5628dc2079af82202d9bfef032c708
Reviewed-on: https://go-review.googlesource.com/39430
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
|
|
This change breaks existing behavior.
Before, a missing ClientConfig.HostKeyCallback would cause host key
checking to be disabled. In this configuration, establishing a
connection to any host just works, so today, most SSH client code in
the wild does not perform any host key checks.
This makes it easy to perform a MITM attack:
* SSH installations that use keyboard-interactive or password
authentication can be attacked with MITM, thereby stealing
passwords.
* Clients that use public-key authentication with agent forwarding are
also vulnerable: the MITM server could allow the login to succeed, and
then immediately ask the agent to authenticate the login to the real
server.
* Clients that use public-key authentication without agent forwarding
are harder to attack unnoticedly: an attacker cannot authenticate the
login to the real server, so it cannot in general present a convincing
server to the victim.
Now, a missing HostKeyCallback will cause the handshake to fail. This
change also provides InsecureIgnoreHostKey() and FixedHostKey(key) as
ready made host checkers.
A simplistic parser for OpenSSH's known_hosts file is given as an
example. This change does not provide a full-fledged parser, as it
has complexity (wildcards, revocation, hashed addresses) that will
need further consideration.
When introduced, the host checking feature maintained backward
compatibility at the expense of security. We have decided this is not
the right tradeoff for the SSH library.
Fixes golang/go#19767
Change-Id: I45fc7ba9bd1ea29c31ec23f115cdbab99913e814
Reviewed-on: https://go-review.googlesource.com/38701
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
See https://groups.google.com/d/msg/Golang-nuts/AoVxQ4bB5XQ/i8kpMxdbVlEJ
R=hanwen
CC=golang-codereviews
https://golang.org/cl/86190043
|
|
R=golang-dev, dave, jpsugar, agl
CC=golang-dev
https://golang.org/cl/14641044
|
|
R=agl, golang-dev, dave
CC=golang-dev
https://golang.org/cl/13176044
|
