- Status Closed
- Percent Complete
- Task Type Bug Report
- Category Base system
- Assigned To No-one
- Operating System All
- Severity Low
- Priority Very Low
- Reported Version Trunk
- Due in Version Undecided
-
Due Date
Undecided
- Private
Opened by alive4ever - 14.02.2017
Last edited by Felix Fietkau - 17.02.2017
FS#512 - uhttpd.init generates certificate with sha1 signature
Tested on lede-x86-64-combined-ext4.img.gz 02142017 snapshot using qemu with tap networking.
On a snapshot LEDE image, installing luci-ssl (mbedtls backend) and enabling uhttpd services makes all http requests to router ip address (192.168.1.1) redirected to https, which is good.
The only downside that the automatically-generated certificate uses SHA1 signature instead of SHA-2 based signature. Maybe the px5g tool doesn’t support SHA-2 signature?
LEDE should generate certificate using SHA-2 based signature algorithm instead of using the deprecated SHA1 signature.
To reproduce this issue, just open a web browser and look at certificate information or use s_client or gnutls-cli to debug.
$ gnutls-cli --no-ca-verification 192.168.1.1 Processed 174 CA certificate(s). Resolving '192.168.1.1:443'... Connecting to '192.168.1.1:443'... - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `CN=LEDE,O=LEDE12fe12b1,L=Unknown,ST=Somewhere,C=ZZ', issuer `CN=LEDE,O=LEDE12fe12b1,L=Unknown,ST=Somewhere,C=ZZ', serial 0x4c850d78, RSA key 2048 bits, signed using RSA-SHA1, activated `2017-02-14 15:41:12 UTC', expires `2019-02-14 15:41:12 UTC', key-ID `sha256:022b3676f5f7e6462d243a51ed156817516c18f725777aecd3dcb6eaee3c3244' Public Key ID: sha1:7ae33ed649825eb4096f3147858122b066af6979 sha256:022b3676f5f7e6462d243a51ed156817516c18f725777aecd3dcb6eaee3c3244 Public key's random art: +--[ RSA 2048]----+ | .. ..+. | | .. . . o | | + . . . | | o . . + . | | . =S* | | + ..B . | | = E..oo+ . | | . . .oo.o | | oo. | +-----------------+ - Description: (TLS1.2)-(ECDHE-RSA-SECP384R1)-(AES-256-GCM) - Session ID: B7:23:E3:1A:06:22:35:AF:DA:E3:80:03:B2:75:8D:FF:87:DD:B2:5D:0C:6E:15:64:85:D7:D7:83:75:10:01:35 - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP384R1 - Curve size: 384 bits - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Server Signature: RSA-SHA512 - Cipher: AES-256-GCM - MAC: AEAD - Compression: NULL - Options: extended master secret, safe renegotiation, - Handshake was completed - Simple Client Mode:
$ openssl s_client -connect 192.168.1.1:443 < /dev/null | openssl x509 -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 1283788152 (0x4c850d78) Signature Algorithm: sha1WithRSAEncryption Issuer: C=ZZ, ST=Somewhere, L=Unknown, O=LEDE12fe12b1, CN=LEDE Validity Not Before: Feb 14 15:41:12 2017 GMT Not After : Feb 14 15:41:12 2019 GMT Subject: C=ZZ, ST=Somewhere, L=Unknown, O=LEDE12fe12b1, CN=LEDE Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:b8:7d:5d:d6:11:77:84:f2:a4:e8:bf:c5:83:a1: 06:25:3f:0c:b6:ec:74:72:36:e4:3b:a1:df:92:c8: b8:33:10:ee:c4:d5:22:24:23:56:f6:b0:b2:63:eb: d7:b3:bf:78:59:78:4a:9f:7b:c0:ef:ef:06:ca:35: 50:a2:9b:4e:37:76:a9:4e:54:d7:38:dc:30:0c:c4: b3:6a:4f:27:26:19:72:2e:de:79:f2:29:8f:49:23: f3:97:02:bc:4f:62:b7:00:ab:c5:8c:8e:ec:53:6c: 11:5b:0b:b8:29:56:87:ed:dd:73:f1:2a:c5:6b:1e: 6b:78:61:50:f3:de:39:8d:96:19:0d:ef:fe:39:10: 30:42:28:0d:d2:4a:21:a4:35:a0:00:1d:01:a2:19: 45:4b:9f:42:9e:f3:be:53:dd:2f:22:1a:39:fb:95: f0:8a:2b:ef:14:9d:06:5c:50:82:2d:83:31:2f:95: a2:25:dc:12:0b:53:af:9a:9c:82:13:a6:2f:51:4a: 9b:f2:5e:79:05:8c:7f:a3:b8:d9:a0:5d:2f:8d:a5: ec:f5:e6:09:29:d0:2f:e3:2e:e7:5b:db:17:6d:2d: 90:31:1f:0d:da:3d:42:af:72:8a:d4:b3:9a:6c:bf: 97:63:16:7a:21:96:08:4b:ec:00:6b:88:a6:61:b0: bc:19 Exponent: 65537 (0x10001) Signature Algorithm: sha1WithRSAEncryption b2:56:d7:53:64:f9:56:39:7a:bf:0c:5b:2a:b5:59:f5:c8:1c: 08:74:44:ae:57:ad:67:d1:02:64:ea:8e:c5:e0:a1:fc:80:12: 10:f3:18:d6:c9:31:fa:10:11:15:d3:b8:12:ed:49:cc:50:14: 3a:eb:78:43:1e:d5:2d:c6:8a:e8:0c:05:e8:ea:f2:76:4a:6c: cd:e8:a1:47:88:50:f7:81:9d:75:41:ec:8f:db:63:ae:3a:fe: 7a:94:8a:f1:2d:b8:a1:89:eb:c5:79:27:09:18:9a:04:8f:e2: 19:91:68:40:4e:14:d5:e8:ff:9a:4d:8b:b1:63:60:39:7b:4a: 1c:5a:49:7b:25:7f:77:7d:a6:b7:ae:3e:da:0b:af:43:a3:cf: e5:c4:7f:f9:18:2c:4c:cf:95:82:2a:18:32:a9:91:fd:3b:39: 2c:41:66:79:37:cf:24:39:2a:88:eb:eb:15:61:a4:30:5b:a5: a5:32:3a:26:20:1d:ac:9d:15:01:2d:b1:b5:f2:6c:27:ef:cc: 62:10:e6:0c:51:a2:02:bf:92:b8:2d:f7:1f:ac:c1:bc:a7:bf: 26:69:49:de:4c:8e:75:c7:40:1f:da:a4:ae:34:5d:bb:8b:f7: 02:37:17:c1:6f:f7:30:35:48:17:ea:e9:b8:72:eb:7a:db:44: 5c:e3:f1:95
Suggested fix:
For openssl backend (uhttpd with luci-ssl-openssl), this problem can be fixed by adding -sha256 parameter to the GENKEY_CMD variable (patch attached).
For px5g/mbedtls back end (uhttpd with luci-ssl), probably needs to some modification to px5g package to spit sha256 signature on certificate creation.
On this image, did you have openssl installed? px5g-mbedtls should already use SHA256.
Fix pushed in r3521-7df998bb6d, and use of SHA256 verified with px5g-mbedtls
Only px5g-standalone is installed on this system, which only generates sha1-signed certificates and pulled by luci-ssl as default px5g backend.
So, the sha1 signature issue lies within px5g-standalone package, which is the default px5g backend when installing luci-ssl.
px5g-mbedtls uses sha256 by default, but users need to specify px5g-mbedtls explicitly when installing luci-ssl.
px5g-standalone seems to have "PROVIDES:=px5g" similarly as px5g-mdebtls. That may lead to opkg selecting the wrong package in some conditions.
That PROVIDES has been added to px5g-standalone in Jan 2017, a bit surprisingly:
https://git.lede-project.org/?p=source.git;a=commit;h=cc66f819b4e778732a32f08f5dc39a2554682b73
One option is to delete the px5g-standalone package. It only produces SHA1 and may lead to confusion.
EDIT:
Other option might be to revert that addition of PROVIDES to px5g-standalone. Anybody who knowingly wants to install it (although it only produces SHA1), should be knowledgeable enough to overcome the opkg dependencies in luci-ssl.
the PROVIDES in px5g-standalone really disturbs things.
I tried installing luci-ssl and it installs px5g-standalone instead of px5g-mbedtls, as is intended.
px5g-mbedtls is selected as px5g backend when building from source and it does sha256 signature by default.
When installing luci-ssl package without explicitly specifying px5g-mbedtls, px5g-standalone is selected, which only generates sha1 signed certificate.
I should open a new bugreport regarding px5g-standalone.
px5g-standalone issue has been reported on
FS#529