Modify

Opened 3 years ago

Last modified 3 years ago

#18232 new defect

OpenWRT 14.07 creates SSL certs with identical serial numbers on different devices

Reported by: painterengr@… Owned by: developers
Priority: high Milestone: Barrier Breaker 14.07
Component: packages Version: Barrier Breaker 14.07
Keywords: ssl https serial number certificate Cc:

Description

Router: TP-Link TL-WR841N HW Ver 9.1
OpenWRT: BARRIER BREAKER (14.07, r42625)

Fire Fox 33.0 web browser is reporting "Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number. (Error code: sec_error_reused_issuer_and_serial)" for 2 brand new TP-Link TL-WR841N wireless routers both running OpenWRT BARRIER BREAKER (14.07, r42625).

AND FF does NOT offer me any choices to "override" this as it does other certificate "issues". I have reported this to FF but they have had this problem at least since 2008 and have NOT provided an exception dialog to handle it. So, it is not usable from FF. I hear that IE browser offers an exception option.

Procedure to reproduce:

  1. On a brand new TL-WR841N wireless router install the latest OpenWRT (14.07).
  2. Configure https (I can supply details if requested)
  3. The router will produce the SSL cert at the end of the config change.
  4. reboot the router.
  5. Using FF access the router at https://192.168.1.1
  6. FF questions the self-signed cert and asks if one wants to accept it and record the exception. I accept the exception.
  7. Take router 2 and perform the same steps 1-5.
  8. FF reports the aforementioned Error code: sec_error_reused_issuer_and_serial and offers no corrective or exception options.

One can make a sound case that any cert generation on different TP-Link OpenWRT routers should produce different serial numbers.

I searched OpenWRT for any reference to this and found nothing. I also tried to find information on how one might manually regenerate the cert with some "other options" that would produce a different result but I didn't find it.

Attachments (1)

OpenWRT SSL cert failure.jpg (38.7 KB) - added by painterengr@… 3 years ago.
Firefox report of the https certificate duplicate serial numbers

Download all attachments as: .zip

Change History (2)

Changed 3 years ago by painterengr@…

Firefox report of the https certificate duplicate serial numbers

comment:1 Changed 3 years ago by anonymous

This sounds like a case about missing entropy, typical to embedded devices. (See e.g. #9631 for more discussion.)

When the device boots, it has the defaults from ROM including date/time etc., so the random number generator is always initialized the same way.

In this case the reason is probably the self-signed-key generator in px5g, which uhttpd uses to generate the SSL key. In px5g the random number generator is initialized with the device time just before the serial generation, which during early boot is probably always 1.1.1970 or something like that. (better havege-based randomization seems to be used for the actual key, but this serial number is generated in a simple way.)

http://git.openwrt.org/?p=openwrt.git;a=blob;f=package/utils/px5g-standalone/src/library/x509write.c;hb=HEAD#l1020

     srand((unsigned int) time(NULL));
     serial = rand();
     if ((ret = asn1_add_int(serial, &chain->serial)) != 0)
         return ret;

Actually, during the boot process the device time should be set based on dates of files in /etc, but that may happen a few seconds later than this key generation.

(Removing the key generated in the initial boot and restarting the uhttpd service should enable it to generate more unique key)

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.