| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
Introduce a helper function that allows fetching the AFI and the
optional SAFI out of an IPAddressFamily. Also add two wrappers that
only fetch and validate the AFI, where validation currently only
means that the length is between 2 and 3.
Use these accessors throughout to simplify and streamline the code.
ok inoguchi jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the legacy stack, a message handling function returns -1 for failure,
0 for need more data and 1 for success (although in extra special cases
2 may also be used). However, the various send/get kex functions only
need to indicate success or failure - switch these to return 0 on failure
(rather than -1) and use normal result testing.
This leaves GOST unchanged for now, as that code is special and needs
extra work.
ok inoguchi@ tb@
|
| |
|
|
|
|
|
|
|
|
|
| |
If we receive something other than a "named curve", send a handshake
failure alert as we're unable to complete the handshake with the given
parameters. If the server responded with a curve that we did not advertise
send an illegal parameter alert.
ok inoguchi@ tb@
|
|
|
|
|
|
|
| |
This provides better symmetry with the parsing code and will allow for
better reuse with the legacy stack, which has different message structures.
ok inoguchi@ tb@
|
|
|
|
| |
ok inoguchi@ tb@
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
CID 345150
|
|
|
|
| |
CID 345156
|
|
|
|
| |
CID 345152
|
|
|
|
| |
CID 345154
|
|
|
|
|
|
| |
_GFp and _GF2m variants.
CID 345155
|
|
|
|
| |
CID 345159
|
|
|
|
| |
CID 345158
|
| |
|
| |
|
|
|
|
| |
CID 345160
|
|
|
|
| |
CID 345141
|
| |
|
|
|
|
| |
prefer this.
|
|
|
|
|
|
|
| |
This is again a straightforward conversion and leads to something which
matches our usual style more.
ok jsing
|
|
|
|
|
|
|
| |
Again, we're dealing with necessarily not fully validated data here,
so a check up front seems prudent.
ok jsing
|
|
|
|
|
|
|
|
| |
This is a more or less straightforward conversion using the new
IPAddressFamily accessor API. As a result, some checks have become
a bit stricter, which is only desirable here.
ok jsing
|
|
|
|
|
|
|
|
|
| |
As mentioned in a previous commit, IPAddressFamily_cmp() can't really
check for trailing garbage in addressFamily->data. Since the path
validation and hence the X.509 validator call X509v3_addr_is_canonical(),
this deals with only partially validated data.
ok jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Define and use MINIMUM() instead of a ternary operator and separate
the code from the declarations. Also, we can spare a line to make the
return legible instead of squeezing it into another ternary operator.
addressFamily->data contains a two-bytes AFI and an optional one-byte
SAFI. This function currently also compares any trailing garbage that
may be present. Since comparison functions can't really error, this
needs to be checked bofore it is used. Such checks will be added in
subsequent commits.
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
Declare IPAddressFamily before using it.
|
| |
|
|
|
|
|
|
| |
unknown address family types.
Pointed out by jsing during review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One reason why this file is hard to read are endless repetitions of
checks and assignments reaching deep inside structs. This can be made
much more readable by adding a bunch of accessors. As a first step,
we deal with IPAddressFamily, where we want to check the type of the
ipAddressChoice member, check whether the inheritance element is present
or access the addressOrRanges field.
This diff already makes minimal use of these accessors to appease -Werror.
More use and additional accessors will follow in later passes.
ok inoguchi jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RFC 3779 section 2.1.2 does a decent job of explaining how IP addresses
are encoded in. What's stored amounts to a prefix with all trailing zero
octets omitted. If there are trailing zero bits in the last non-zero octet,
bs->flags & 7 indicates how many. addr_expand() expands this to an address
of length 4 or 16 depending on whether we deal with IPv4 or IPv6.
Since an address can be the lower or the upper bound of a prefix or
address range, expansion needs to be able to zero-fill or one-fill the
unused bits/octets. No other expansion is ever used, so simplify the
meaning of fill accordingly. There's no need to special case the case
that there are no unused bits, the masking/filling is a noop.
ok jsing
|
|
|
|
| |
in make_IPAddressFamily()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The IPAddrBlocks type, which represents the IPAddrBlocks extension,
should have exactly one IPAddressFamily per AFI+SAFI combination to
be delegated. make_IPAddressFamily() first builds up a search key
from the afi and safi arguments and then looks for an existing
IPAddressFamily with that key in the IPAddrBlocks that was passed
in. It returns that if it finds it or allocates and adds a new one.
This diff preserves the current behavior that the afi and *safi
arguments are truncated to 2 and 1 bytes, respectively. This may
change in the future.
ok inoguchi jsing
|
|
|
|
|
|
|
| |
The ASN.1 template for IPAddressFamily doesn't mark either of its two
members as optional, so they are allocated by IPAddressFamily_new().
ok inoguchi jsing
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per RFC 3779 2.2.3.3, the addressFamily field contains the 2-byte AFI
and an optional 1-byte SAFI. Nothing else. The optional SAFI is nowhere
exposed in the API. It is used expliclty only for pretty printing. There
are implicit uses in a few places, notably for sorting/comparing where
trailing garbage would be erroneously taken into account.
Erroring in this situation will let us avoid this in upcoming revisions.
ok inoguchi jsing
|
|
|
|
|
|
|
|
|
|
|
| |
The manual byte bashing is performed more safely using this API
which would have avoided the out-of-bounds read that this API had
until a few years back.
The API is somewhat strange in that it uses the reserved AFI 0 as an
in-band error but it doesn't care about the reserved AFI 65535.
ok inoguchi jsing
|
|
|
|
| |
Discussed with tb@
|
|
|
|
| |
These are generated using the make-certs.sh script.
|
|
|
|
|
|
|
| |
This will allow us to generate a variety of client and server certificates,
including expired and revoked certificates, using both RSA and ECDSA.
Discussed with tb@
|
| |
|
|
|
|
| |
CID 345118
|
|
|
|
| |
CID 345114
|
| |
|
|
|
|
| |
CID 345111
|
|
|
|
| |
CID 345119
|