4 ms·

How could certificates ever work in embedded applications connected to consumer LANs that provide interfaces over HTTP? Aren't certificates tied to IP addresses

by m_eiman 12y ago

How could certificates ever work in embedded applications connected to consumer LANs that provide interfaces over HTTP? Aren't certificates tied to IP addresses, which wouldn't work with e.g. DHCP? Not to mention certificate expiration and updates…

icebraining 12y ago
Aren't certificates tied to IP addresses No, just to domains.
stephen_g 12y ago
Certificates are generally based on hostnames. You can put an IP as the common name but it's problematic (and you can't get one signed by most authorities for an IP address as far as I know). Generally the devices just generate a self-signed certificate and you have to click through the warning.
- m_eiman 12y ago
  Ok, so it's just a horrible user experience then :]
  - bodyfour 12y ago
    Exactly. Worse, it trains users to ignore cert warnings. I don't have any problems with the campaigns to make the public internet HTTPS-only. However, for software inside an intranet, or software that just wants to expose an interface on http://127.0.0.1:*someport* http://127.0.0.1:*someport* non-SSL is the better default. If people want to protect their intranet that's great, but it means that they have to go through the work of buying a cert, since only they know the hostname it will be exposed as. That's a poor initial-install experience.
    - Karunamon 12y ago
      My view is starting to change on this.. can you really trust a LAN beyond a certain size? (That size being what one person can comfortably architect and maintain.) Nowadays, I'm a firm believer in "encrypt all the things", but that's because I'm a geek and can deal with the PITA. There needs to be either an encryption mechanism that's completely separate from authentication, or the use case of LAN encryption for regular people needs to be addressed in some other way.
      - jeremie 12y ago
        I'm a big believer in a (local/p2p) transport encryption mechanism /in addition to/ one for auth, and for it to be transparent to any UX... that's very much our goals for telehash v3 :)
forgottenpass 12y ago
Tied to domains, but you still have a good point. Try getting a cert for "foo.myhouse.lan" (and that ignores complications of coordinating hostnames of embedded device ahead of time). On a manged corporate intranet, Active Directory can push out a new CA and your computer trust whatever certs the local IT department wants to cook up, but it breaks down with a BYOD office or SOHO lan. I manage a few intranet websites, this encryption requirement basically kills any interest I had in experimenting with HTTP/2 which was already miniscule. I'm not seeing the use case for HTTP/2 unless you're already all-https or in the Top N websites and want to slim down bandwidth use.
michaelbuckbee 12y ago
Typing IP addresses to certs is a certificate vendor addition to standard SSL issuance policies. Some of the high end (as denoted by more insurance) certs from say Symantec will be "locked" to an IP address, but again this is mostly handwaving.

by m_eiman 12y ago

icebraining 12y ago

Aren't certificates tied to IP addresses No, just to domains.

stephen_g 12y ago

Certificates are generally based on hostnames. You can put an IP as the common name but it's problematic (and you can't get one signed by most authorities for an IP address as far as I know). Generally the devices just generate a self-signed certificate and you have to click through the warning.

m_eiman 12y ago
Ok, so it's just a horrible user experience then :]
- bodyfour 12y ago
  Exactly. Worse, it trains users to ignore cert warnings. I don't have any problems with the campaigns to make the public internet HTTPS-only. However, for software inside an intranet, or software that just wants to expose an interface on http://127.0.0.1:*someport* http://127.0.0.1:*someport* non-SSL is the better default. If people want to protect their intranet that's great, but it means that they have to go through the work of buying a cert, since only they know the hostname it will be exposed as. That's a poor initial-install experience.
  - Karunamon 12y ago
    My view is starting to change on this.. can you really trust a LAN beyond a certain size? (That size being what one person can comfortably architect and maintain.) Nowadays, I'm a firm believer in "encrypt all the things", but that's because I'm a geek and can deal with the PITA. There needs to be either an encryption mechanism that's completely separate from authentication, or the use case of LAN encryption for regular people needs to be addressed in some other way.
    - jeremie 12y ago
      I'm a big believer in a (local/p2p) transport encryption mechanism /in addition to/ one for auth, and for it to be transparent to any UX... that's very much our goals for telehash v3 :)

forgottenpass 12y ago

Tied to domains, but you still have a good point. Try getting a cert for "foo.myhouse.lan" (and that ignores complications of coordinating hostnames of embedded device ahead of time). On a manged corporate intranet, Active Directory can push out a new CA and your computer trust whatever certs the local IT department wants to cook up, but it breaks down with a BYOD office or SOHO lan. I manage a few intranet websites, this encryption requirement basically kills any interest I had in experimenting with HTTP/2 which was already miniscule. I'm not seeing the use case for HTTP/2 unless you're already all-https or in the Top N websites and want to slim down bandwidth use.

michaelbuckbee 12y ago

Typing IP addresses to certs is a certificate vendor addition to standard SSL issuance policies. Some of the high end (as denoted by more insurance) certs from say Symantec will be "locked" to an IP address, but again this is mostly handwaving.