Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

FS#512 - uhttpd.init generates certificate with sha1 signature #5550

Closed
openwrt-bot opened this issue Feb 14, 2017 · 8 comments
Closed

FS#512 - uhttpd.init generates certificate with sha1 signature #5550

openwrt-bot opened this issue Feb 14, 2017 · 8 comments
Labels
flyspray

Comments

@openwrt-bot
Copy link

alive4ever:

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.
@openwrt-bot
Copy link
Author

nbd:

On this image, did you have openssl installed? px5g-mbedtls should already use SHA256.

@openwrt-bot
Copy link
Author

nbd:

Fix pushed in r3521-7df998bb6d, and use of SHA256 verified with px5g-mbedtls

@openwrt-bot
Copy link
Author

alive4ever:

Only px5g-standalone is installed on this system, which only generates sha1-signed certificates and pulled by luci-ssl as default px5g backend.

@openwrt-bot
Copy link
Author

alive4ever:

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.

@openwrt-bot
Copy link
Author

hnyman:

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.

@openwrt-bot
Copy link
Author

hnyman:

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.

root@LEDE:~# opkg install luci-ssl
Installing luci-ssl (git-17.048.25667-9726e26-1) to root...
Downloading http://downloads.lede-project.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/luci/luci-ssl_git-17.048.25667-9726e26-1_all.ipk
Installing libustream-mbedtls (2016-07-02-ec80adaa-2) to root...
Downloading http://downloads.lede-project.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/libustream-mbedtls_2016-07-02-ec80adaa-2_arm_cortex-a15_neon-vfpv4.ipk
Installing libmbedtls (2.4.0-2) to root...
Downloading http://downloads.lede-project.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/libmbedtls_2.4.0-2_arm_cortex-a15_neon-vfpv4.ipk
Installing px5g-standalone (2) to root...
Downloading http://downloads.lede-project.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/px5g-standalone_2_arm_cortex-a15_neon-vfpv4.ipk
Configuring libmbedtls.
Configuring libustream-mbedtls.
Configuring px5g-standalone.
Configuring luci-ssl.

@openwrt-bot
Copy link
Author

alive4ever:

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.

@openwrt-bot
Copy link
Author

alive4ever:

px5g-standalone issue has been reported on FS#529

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
flyspray
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@openwrt-bot