| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
feedback and ok tb@ jsing@ markus@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In ssh, when an agent fails to return a RSA-SHA2 signature when
requested and falls back to RSA-SHA1 instead, retry the signature to
ensure that the public key algorithm sent in the SSH_MSG_USERAUTH
matches the one in the signature itself.
In sshd, strictly enforce that the public key algorithm sent in the
SSH_MSG_USERAUTH message matches what appears in the signature.
Make the sshd_config PubkeyAcceptedKeyTypes and
HostbasedAcceptedKeyTypes options control accepted signature algorithms
(previously they selected supported key types). This allows these
options to ban RSA-SHA1 in favour of RSA-SHA2.
Add new signature algorithms "rsa-sha2-256-cert-v01@openssh.com" and
"rsa-sha2-512-cert-v01@openssh.com" to force use of RSA-SHA2 signatures
with certificate keys.
feedback and ok markus@
|
|
|
|
|
|
| |
This avoids a potential side channel timing leak.
ok djm@ markus@
|
|
|
|
| |
ok deraadt@ dtucker@
|
| |
|
|
|
|
|
| |
check that the negotiated algorithm matches the type in the
signature (only matters for RSA SHA1/SHA2 sigs). ok markus@
|
|
|
|
| |
remaining bit that it still used into ssh-rsa.c; ok markus
|
|
|
|
| |
do not meet this requirement. ok markus@
|
|
|
|
| |
special case elsewhere.
|
| |
|
|
|
|
| |
ok djm@
|
|
|
|
| |
ok dtucker@
|
| |
|
|
|
|
|
| |
based on draft-rsa-dsa-sha2-256-03.txt and draft-ssh-ext-info-04.txt;
with & ok djm@
|
|
|
|
|
| |
the function itself with only negative numbers or zero assigned to it.
bz#2460
|
| |
|
|
|
|
|
|
|
|
|
| |
existing API is offered as a set of wrappers.
with and ok markus@
Thanks also to Ben Hawkes, David Tomaschik, Ivan Fratric, Matthew
Dempsky and Ron Bowes for a detailed review a few months ago.
|
| |
|
|
|
|
|
|
| |
rather than calling OpenSSL EVP_Digest* directly. Will make it easier
to build a reduced-feature OpenSSH without OpenSSL in future;
feedback, ok markus@
|
|
|
|
|
|
| |
obsolete RSA+MD5 signature scheme. it will still be possible to connect
with these clients/servers but only DSA keys will be accepted, and we'll
deprecate them entirely in a future release. ok markus@
|
| |
|
|
|
|
|
|
| |
the ECDSA/Ed25519 ones: use key_type_plain() when checking the key type
rather than tediously listing all variants, use __func__ for debug/
error messages
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
string extracted from the buffer contains no embedded \0 characters*
This prevents random (possibly malicious) crap from being appended to
strings where it would not be noticed if the string is used with
a string(3) function.
Use the new API in a few sensitive places.
* actually, we allow a single one at the end of the string for now because
we don't know how many deployed implementations get this wrong, but don't
count on this to remain indefinitely.
|
|
|
|
|
| |
data before returning. AFAIK not exploitable in the SSH protocol.
"groovy" deraadt@
|
| |
|
|
|
|
|
|
| |
timing information by short-circuiting like memcmp() and use it for
some of the more sensitive comparisons (though nothing high-value was
readily attackable anyway); "looks ok" markus@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
following changes:
move the nonce field to the beginning of the certificate where it can
better protect against chosen-prefix attacks on the signature hash
Rename "constraints" field to "critical options"
Add a new non-critical "extensions" field
Add a serial number
The older format is still support for authentication and cert generation
(use "ssh-keygen -t v00 -s ca_key ..." to generate a v00 certificate)
ok markus@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenSSH certificate key types are not X.509 certificates, but a much
simpler format that encodes a public key, identity information and
some validity constraints and signs it with a CA key. CA keys are
regular SSH keys. This certificate style avoids the attack surface
of X.509 certificates and is very easy to deploy.
Certified host keys allow automatic acceptance of new host keys
when a CA certificate is marked as trusted in ~/.ssh/known_hosts.
see VERIFYING HOST KEYS in ssh(1) for details.
Certified user keys allow authentication of users when the signing
CA key is marked as trusted in authorized_keys. See "AUTHORIZED_KEYS
FILE FORMAT" in sshd(8) for details.
Certificates are minted using ssh-keygen(1), documentation is in
the "CERTIFICATES" section of that manpage.
Documentation on the format of certificates is in the file
PROTOCOL.certkeys
feedback and ok markus@
|
|
|
|
|
| |
ok djm, sort of ok stevesk
makes the pain stop in one easy step
|
| |
|
|
|
|
| |
Theo nuked - our scripts to sync -portable need them in the files
|
|
|
|
|
|
|
|
| |
xrealloc(p, new_nmemb, new_itemsize).
realloc is particularly prone to integer overflows because it is almost
always allocating "n * size" bytes, so this is a far safer API;
ok deraadt@
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
switch to share/misc/license.template
|
|
|
|
|
| |
insist on len == hlen + oidlen, since this breaks some smartcards)
bugzilla #592; ok djm@
|
| |
|
| |
|
| |
|
|
|
|
| |
for authentication; ok deraadt/djm
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
a signature of RSA_size. the drafts says the signature is transmitted
unpadded (e.g. putty does not pad), reported by anakin@pobox.com
|