The syntax of public key certificates can be found in RFC 5280 section
4.1. The relevant part of the syntax is the following:
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
... remaining fields omitted ...
}
The version field has a default value of v1. RFC 5280 section 4.1.2.1
says the following:
If only basic fields are present, the version SHOULD be 1 (the value
is omitted from the certificate as the default value); however, the
version MAY be 2 or 3.
To help detect if the version field is present or not, the type of the
version field has an explicit tag of [0]. Due to this tag, if the
version field is present, its encoding will have an identifier octet
that is distinct from that of the serialNumber field.
ITU-T X.690 specifies how a value of such a type should be encoded with
DER. There is a PDF of X.690 freely available from ITU-T. X.690 section
8.1.2 specifies the format of identifier octets which is the first
component of every encoded value. Identifier octets encode the tag of a
type. Bits 8 and 7 encode the tag class. Bit 6 will be 0 if the encoding
is primitive and 1 if the encoding is constructed. Bits 5 to 1 encode
the tag number.
X.690 section 8.14 specifies what the identifier octet should be for
explicitly tagged types. Section 8.14.3 says if implicit tagging is not
used, then the encoding shall be constructed. The version field uses
explicit tagging and not implicit tagging, so its encoding will be
constructed. This means bit 6 of the identifier octet should be 1.
X.690 section 8.14 and Annex A provide examples. Note from their
examples that the notation for tags could look like [APPLICATION 2]
where both the tag class and tag number are given. For this example, the
tag class is 1 (application) and the tag number is 2. For notation like
[0] where the tag class is omitted and only the tag number is given, the
tag class will be context-specific.
Putting this all together, the identifier octet for the DER encoding of
the version field should have a tag class of 2 (context-specific), bit 6
as 1 (constructed), and a tag number of 0.
Signed-off-by: Ivan Abrea <ivan@algosolutions.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Good news that TLS_RSA_WITH_AES_256_CBC_SHA256 still works with new code ;)
This change adds inevitable extension to have different sized hashes and AES key sizes.
In libbb, md5_end() and shaX_end() are extended to return result size instead of void -
this helps *a lot* in tls (the cost is ~5 bytes per _end() function).
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Hoped this can make cdn.kernel.org to like us more. Nope.
While at it, made error reporting more useful.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
A new applet, ssl_client, is the TLS debug thing now.
It doubles as wget's NOMMU helper.
In MMU mode, wget still forks, but then directly calls TLS code,
without execing.
This can also be applied to sendmail/popmail (SMTPS / SMTP+starttls support)
and nc --ssl (ncat, nmap's nc clone, has such option).
function old new delta
tls_handshake - 1691 +1691
tls_run_copy_loop - 443 +443
ssl_client_main - 128 +128
packed_usage 30978 31007 +29
wget_main 2508 2535 +27
applet_names 2553 2560 +7
...
xwrite_encrypted 360 342 -18
tls_main 2127 - -2127
------------------------------------------------------------------------------
(add/remove: 4/1 grow/shrink: 13/8 up/down: 2351/-2195) Total: 156 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
As it turns out, it goes only up to "inbuf_size:4608"
for kernel.org - fixed 18kb buffer was x4 larger than necessary.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
With tls_has_buffered_record(), entire kernel.org response
is printed at once, without 6 second pause to see its delayed EOF.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
For the first time
printf "GET / HTTP/1.1\r\nHost: kernel.org\r\n\r\n" | ./busybox tls kernel.org
successfully reads entire server response and TLS shutdown.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Successfully finishes handshake with test servers using NULL-SHA256
cipher.
The "only" thing remaining before there is a chance
this can actually work with real servers is AES encrypt/decrypt.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
$ ./busybox tls kernel.org
insize:0 tail:0
got block len:74
got HANDSHAKE
got SERVER_HELLO
insize:79 tail:4406
got block len:4392
got HANDSHAKE
got CERTIFICATE
entered der @0x8f7e723:0x30 len:1452 inner_byte @0x8f7e727:0x30
entered der @0x8f7e727:0x30 len:1172 inner_byte @0x8f7e72b:0xa0
skipped der 0xa0, next byte 0x02
skipped der 0x02, next byte 0x30
skipped der 0x30, next byte 0x30
skipped der 0x30, next byte 0x30
skipped der 0x30, next byte 0x30
skipped der 0x30, next byte 0x30
entered der @0x8f7e830:0x30 len:418 inner_byte @0x8f7e834:0x30
skipped der 0x30, next byte 0x03
entered der @0x8f7e843:0x03 len:399 inner_byte @0x8f7e847:0x00
copying key bytes:399, first:0x00
insize:4397 tail:9
got block len:4
got SERVER_HELLO_DONE
Now need to teach it to send ClientKeyExchange...
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
