ConnMan does not support certificate detail verification

asked 2014-01-15 16:56:28 +0200

Karri Huhtanen

1928 ●19 ●23 ●31

https://www.linkedin.com/...

updated 2014-02-13 00:04:35 +0200

prometoys

1363 ●8 ●14 ●16

http://www.prometoys.net/

I looked into ConnMan and especially into WPA Enterprise authentication used for example in eduroam and company networks. Currently it seems possible via developer mode to install configuration file for ConnMan, which allows the wpa_supplicant to verify that the authentication server certificate is certified by certain certificate authority (CA). This however leaves an option to perform man-in-the-middle attack and catching the user credentials using different certificate signed by the same CA.

An example of this:

Company's or University's authentication server's certificate is a Thawte's SSL123 certificate signed by Thawte CA. ConnMan profile is configured to verify that the authentication server's certificate is verified by Thawte CA. Because ConnMan does not support certificate detail verification such as for example CN (usually the authentication server name), ConnMan instructs wpa_supplicant to accept any Thawte CA verified certificate. This creates an opportunity to set up man-in-the-middle attack box where some other Thawte signed certificate is used to lure device to connect and send the user credentials to the attacker.

This same problem exists for Android platform and most Linux distributions even if the wpa_supplicant used for connecting to WiFi networks is perfectly capable to do certificate detail and fingerprint checking.

edit retag flag offensive close delete

Comments

1

isn't that a bug? did you submit a bug?

dafeujolla ( 2014-03-06 18:46:27 +0200 )edit

@dafeujolla I have not submitted it in the ConnMan bug database. This however should be a well-known certificate check problem and it seems that some vendor's have already made patches themselves to cover this (e.g. Google and Chromium). Also this affects UI if WPA Enterprise settings are to be set also manually in the next SailfishOS versions.

Karri Huhtanen ( 2014-03-07 08:50:16 +0200 )edit

1

@karri-huhtanen Do you have link to the patches google made? I couldn't find it. I had a closer look in the code of connman and wpa_supplicant and it shouldn't be too difficult to add certificate detail verification to connman. I think it can be done in the same way as the support for an anonymous identitiy was added in this commit: http://git.kernel.org/cgit/network/connman/connman.git/commit/?id=1d5429cf57aad9feb9a33f8a1327a88298b7976d&context=1

rincewind ( 2016-08-01 13:46:36 +0200 )edit

there is not even an upstream bug report (you can't just register and create one), so which is the best way to make upstream aware of this security issue?

tad ( 2016-10-10 12:10:25 +0200 )edit

8

answered 2014-01-15 17:07:21 +0200

Karri Huhtanen

1928 ●19 ●23 ●31

https://www.linkedin.com/...

The problem to be solved here is the connection manager (in Jolla ConnMan is used). The used connection manager should be able to transfer more detailed WiFI configuration to wpa_supplicant or at least make it possible to transfer freeform instructions to the wpa_supplicant. Wpa_supplicant supports all kinds of configuration options including certificate detail checking as well as various EAP-methods used in WiFi authentication. The connection managers are just holding wpa_supplicant down providing only a very limited subset of features and configuration options to be configured through them.

Some solutions for this might be (in no particular order):

Fixing and/or enhancing ConnMan (or other connection manager) and pushing changes upstream
Requesting ConnMan developers to add certificate detail verification and possible other features (network ordering, priorisation,certificate fingerprinting) to ConnMan. Integrating new, enhanced ConnMan part of Mer/Jolla core platform.
Replacing ConnMan with some connection manager with better capabilities
Separating WiFi network management and configuration from ConnMan and communicating directly with wpa_supplicant.

edit flag offensive delete publish link

Comments

Example of wpa_supplicant capabilities: http://hostap.epitest.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf

Karri Huhtanen ( 2014-01-15 17:18:50 +0200 )edit

Example of ConnMan capabilities: http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt

Karri Huhtanen ( 2014-01-15 17:19:53 +0200 )edit

1

it would be sufficient to pass subject_match="CN=name_of_authentication_server" to wpa_supplicant, I tried to add the line to /var/lib/connman/wifi_eduroam.config but it is completely ignored

dafeujolla ( 2014-03-06 18:49:11 +0200 )edit

Yes. A lot of these things could be solved by ConnMan just passing the key-value pair to wpa_supplicant. In Chromium version of ConnMan some of these have been already been fixed. If Jolla does not fix this, maybe I'll go to next Jolla meeting here in Tampere and ask how to compile and replace these system software with working ones?

Karri Huhtanen ( 2014-03-07 08:26:56 +0200 )edit

this is a a serious security problem but doesn't have an upstream or Jolla ticket?

tad ( 2015-06-03 14:10:53 +0200 )edit

3

answered 2017-04-04 14:07:59 +0200

rincewind
96 ●6 ●6

With sfos 2.1.0.x connman has the patch applied to support certificate detail verification. You can use one or more of the 4 new config options in a connman config file:

SubjectMatch
AltSubjectMatch
DomainSuffixMatch
DomainMatch

They are simply passed to the corresponding wpa_supplicant options. The patch is here: https://git.merproject.org/mer-core/connman/commit/ddfbb2063bc6db2cf5fefbb093147506f3a35e3c

edit flag offensive delete publish link

1

answered 2014-01-16 09:46:44 +0200

Karri Huhtanen

1928 ●19 ●23 ●31

https://www.linkedin.com/...

This is a network based workaround for enterprises and organisations, not a solution to the problem. I forgot to add this yesterday, when I wrote the question and answer.

To avoid man-in-the-middle attacks or make them a bit harder, one can always set up private CA for signing and verifying authentication server certificates. With private CA and with its properly configured verification it is less likely that the attacker would be able to gain access to a certificate signed by the same CA and use it for man-in-the-middle attacks.

The problem with this is how to transfer and install the private CA certificate to the end user device as they all need it there. Most of the platforms are able to get CA certificate installed if it is sent by email or accessed via web browser. Many of those also have certificate managers to be able to do this also. Currently the only way how to do this on Jolla is developer mode and copying the configurations and certificates manually so it is pretty much on user's own responsibility as there are not UIs to do this.

edit flag offensive delete publish link

ConnMan does not support certificate detail verification

Comments

3 Answers

Comments

Question tools

Stats

Related questions

ConnMan does not support certificate detail verification

Comments

3 Answers

Comments

Question tools

Public thread

Stats

Related questions