04 May 2011

Android default (weak) signing configuration for the developer certificates


Some months ago I created a couple of Android applications.  As every Android developer  knows, in order to deploy applications on Android devices, these need to be signed. In other platforms like IOS, Symbian, Java or Windows Mobile, the signing process is a method used to prove the source of an application. Once an application is signed by a known certification authority, the platform will grant different execution permissions. Android  used code signing slightly different. The developer creates its own self signed certificate and uses this to sign any application he releases. This allows the platforms to recognize updates and also allow secure inter application communication.  The reason is simple, if there was no way to relate an application to its owner it would be trivial to impersonate him or her and deliver fake applications updates.

Without wanting to dig into the controversy between open and closed models, IOS vs Android, the part that caught my attention was that the developer would create a self signed certificate on his own and that that the only requirement is that the certificate must be valid until 2034. Today we all know that MD5 is proven to be weak and that key sizes should be at least 2048b, especially if we need to use it for a few years. On the other hand the default Android tools I used to create the certificate suggested to use a 1024b key and MD5 which is not a good idea, especially if that would be my identification until 2033!!

With that in mind I was curious to see how the digital certificates used to sign Android applications would look like. I analyzed nearly 4.000 applications, extracted the certificates and put together some statistics. For this I used unique certificates, which means that if two applications (in most cases these were updates) were signed with the same certificate I only took into consideration one occurrence.

First lets have a look at the algorithms being used:

As you can see the most used algorithm is RSA with SHA1 as a hashing algorithm but nearly one every 5 uses MD5 as a hashing algorithm. 
The strongest hashing algorithm found was SHA256 (1 occurrence, removed from the char) and the weakest MD5. It´s remarkable to see a 6% of DSA which is a n algorithm rarely used for X509 certificates, although perfectly valid.

Regarding key sizes for RSA we have the following distribution:

The most used key size is 1024b. Although I removed them from the pie charts, the weakest key size was 1023b (9 occurrences) and the strongest 8192b (1 occurrence). 

Developers, and some sysadmins too, tend to see digital certificates, and everything else around it, private keys, Root CAs, CRLs, etc as an annoyance and in the best cases as another “configuration” file.   Having in mind that Android forces you to use selfsigned certificates valid until 2033 it would be good to invest some time explaining developers the importance of the certificate/key and even more important enforce the use by default of stronger algorithms. Seeing the capabilities of the platform I don´t understand why Google did not enforce a minimum key length of 2048b and SHA1 or even better SHA256, instead of using default weaker settings especially when forcing developers to generate certificates valid for so long.
Posted by at 1 comment:
Labels:

17 February 2011

How to validate the Subject Key Identifier (SKI) from a X509 certificate

Some days ago I received an odd complain that some of the Root CAs we use had the wrong Subject Key Identifier (SKI). I knew that the claim was false but I also knew that I'll have to prove it. The guy did dig on our own specifications and calculated the SKI as we required, the hash of the certificate public key but unfortunately the identifiers did not match.

In order to reproduce the problem I extracted the public key of the Root CA, converted to DER, hashed it with SHA1 and verified that indeed the hash did not match. Let’s do a demonstration of what I did with a public available Root CA:



Now let's calculate the SHA1 of the public key:



As reported, both hashes did not match!

At this point I was a bit confused and decided to read some documentation before moving forward. After some reading I found the answer in the 4.2.1.2 section of the the RFC3280 “Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile ” (http://www.ietf.org/rfc/rfc3280.txt)



In our case we use method 1) for the SKI but in my calculations I was taking into consideration the whole public key, including tag, length, etc, while I should have used the key bits only.
With the following command I was able to locate the “BIT STRING” with the naked key:



And I only need to extract it and put it on a file in DER format:



The remaining part was to calculate the SHA1 hash which was the same as the SKI:



The same method was used to verify the SKI of a Root CA using SHA256 as a hashing algorithm.
Posted by at 9 comments:

27 September 2010

Mobile operators header enrichment assessment 6/6: Summary

During the last weeks I have been posting the results of header enrichment assessment I've done in several mobile operators. Let's do a quick check and summarize the results.

1) All operators in the same country have similar configurations. I was surprised to see how mobile operators appear to mimic other operators in the same territory.
2) Most operators have transparent proxies operating on the "Internet" connections.
3) As seen, some operators allow third parties to track users without the user consent and without allowing them to change or hide these traces. They add an HTTP header with an ID that uniquely identify the user. Some operators will change that ID every 24h like Orange Spain or Orange UK but some will keep the same ID forever. The worst ranking operators from the user privacy point of view are TIM Italy, Vodafone Italy, Telefonica Spain and Vodafone Spain.
4) Several ones are disclosing unnecessary information that reveals data that could be misused. From the information disclosure point of view the worst operator is Orange UK followed by SFR in France.
5) The winner of the header overhead would be Orange Spain which doubles all the Accept Headers,
6) and the winners of the header manipulation are TIM in Italy and Eplus in Germany.
I hope you enjoyed this series of posts. Feel free to leave your comment and let me know if some of the results change.
Posted by at 3 comments:

22 September 2010

Mobile operators header enrichment assessment: Part 5/6 - UK

And today, the last group of mobile operators assessed. We had a look at the mobile operators in the UK: TMobile, Vodafone, Orange, O2/Telefonica and 3, and these are the results:

=== TMobile UK through WAPGW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
Cache-Control: max-age=43200
Connection: keep-alive

=== TMobile UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Cache-Control: max-age=43200
Connection: keep-alive

We can see that TMobile UK is adding just a couple of proxy related HTTP headers and also that all the request in the Internet connections go trough a transparent proxy.

=== Vodafone UK through WAPGW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Encoding: deflate, gzip, identity
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
Via: HTTP/1.1 begwsl12 (XMS 724Solutions HTG XFW_004_M00_B133 20100521.012244)
Connection: close

=== Vodafone UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Encoding:
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Connection: TE, close

In Vodafone UK we have a similar behavior as in TMobile, all connections go through a proxy, even the Internet ones.  In the WAP connection they add a "Via" HTTP header. Although that is a standard proxy header, seeing that it is not added by most operators I would not add it here either.

=== O2/Telefonica through WAPGW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
X-Forwarded-For: 10.86.161.95
Cache-Control: max-age=43200
Connection: keep-alive

=== O2/Telefonica UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Cache-Control: max-age=43200
Connection: keep-alive

In O2/Telefonica we see a similar behavior as in Vodafone UK or TMobile UK. Everthing goes trough a proxy but in here we see that the WAP connection adds the X-Forwarded-For, which, although it is a standard, nowadays adds little or no value.

=== 3 UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Cache-Control: max-stale=0
Connection: Keep-Alive
X-BlueCoat-Via: 03F39CF1D18B00C3

3 in UK, as 3 in Italy, does not have a WAP connection with a fixed proxy.  Nevertheless we see they use a transparent proxy too as they are adding some extra HTTP headers.

=== Orange UK through WAPGW/Proxy ===
X-ICAP-Version: 1.0
Connection: keep-alive
Content-Length: 0
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
X-Nokia-RemoteSocket: 10.37.7.162:11961
X-Nokia-LocalSocket: 193.35.132.107:8080
X-Nokia-Gateway-Id: NBG/1.0.91/91
X-Nokia-BEARER: GPRS
X-Nokia-CONNECTION_MODE: TCP
X-Orange-ID: 2/oj/g2sxXXXXXXXXXXXX==
X-Forwarded-For: 10.37.7.162, 193.35.132.106
Via: 1.1, 1.1 pg-proxy1 (NetCache NetApp/6.0.6P1)

=== Orange UK direct INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
X-Nokia-BEARER: GPRS
X-Operator-Domain: orange.co.uk
X-Orange-Roaming: NO
X-Orange-ID: OR4B9UD7xXXXXXXXXXXXXX==
Via: 1.1 pg_squid4_3 (squid)
X-Forwarded-For: 172.24.36.9
Cache-Control: max-age=259200
Connection: keep-alive

In Orange UK we see one of the examples of HTTP header overhead. We can see all the useless Nokia headers and this time I´d like to highlight the following ones:

X-Nokia-RemoteSocket: 10.37.7.162:11961
X-Nokia-LocalSocket: 193.35.132.107:8080

The bigmouthed Nokia GW is telling us that the mobile device has the IP  10.37.7.162 and a socket connecting from port 11961 to the GW IP 193.35.132.107 and port 8080. I can think of a couple of tests that could be done with this information...

Another piece of useful information is that Orange is using a Nokia GW for the WAP connection and a Squid proxy as a transparent proxy.
Regarding the header

X-Orange-ID: OR4B9UD7xXXXXXXXXXXXXX==

this is a unique ID that is being updated every 24h. Needed?.... not really. Harmful? not too much.


Except Orange, the Mobile Operators in the UK seam to do a good job, not allowing third parties to track their customers and having light proxys. What they all have is a transparent proxy on the Internet connection which seems to be quite common in most operators. Next post will be a summary of the assessed operators.
 
Posted by at No comments:

21 September 2010

Mobile operators header enrichment assessment: Part 4/6 - Spain

This time we´ll go for the main mobile operators in Spain: Orange, Vodafone and Telefonica/Movistar.
See the previous posts if you need more information on the procedure.

=== Orange Spain through WAP GW/Proxy ===TE: deflate,gzip;q=0.3
Accept: text/html, text/vnd.wap.wml, application/vnd.wap.html+xml, application/xhtml+xml, application/vnd.wap.xhtml+xml, text/x-wap.wml, text/x-hdml, text/vnd.sun.j2me.app-descriptor, application/java-archive, application/octet-stream, image/png, image/gif, image/jpg, image/jpeg, */*, text/x-vcard, text/x-vcalendar, image/vnd.wap.wbmp
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
Content-length: 0
Via: WTP/1.1 nwg3 (Nokia WAP Gateway 4.1/CD21/4.1.116)
X-Nokia-CONNECTION_MODE: TCP
X-Nokia-BEARER: CSD
X-Nokia-GATEWAY_ID: NWG/4.1/Build116
x-nokia.wia.accept.original: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,image/png,image/gif,image/jpg,image/jpeg,*/*,text/x-vCard,text/x-vCalendar,image/vnd.wap.wbmp
Connection: close
x-up-calling-line-id: RKWsZys5JJXXXXXXXXXXXX==

=== Orange Spain direct INTERNET connection===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir

As you can see the GW in Orange Spain is adding a lot of overhead. For what we have seen before it seems to be a standard procedure on Nokia GWs but in my eyes this configuration is the worst we have seen so far. The GW is duplicating the "Accept" header which is the header with the biggest amount of information. For instance a random Nokia Series 60 device has the following "Accept" header:

application/vnd.ces-quicksheet, audio/wav, audio/x-wav, audio/basic, audio/x-au, audio/au, audio/x-basic, video/mp4, video/mpeg4, video/3gpp, application/vnd.rn-realmedia, audio/amr-wb, audio/amr, audio/mp3, application/sdp, audio/sp-midi, audio/x-beatnik-rmf, audio/midi, audio/aac, audio/mpeg, audio/3gpp, audio/mp4, application/java-archive, text/vnd.sun.j2me.app-descriptor, text/html, application/vnd.wap.xhtml+xml, application/xhtml+xml, application/vnd.wap.wmlc, text/vnd.wap.wml, application/vnd.wap.wbxml1, application/vnd.wap.wmlscriptc, multipart/mixed, application/x-javascript, text/ecmascript, application/x-nokiaGameData, application/vnd.ces-quickword, application/vnd.ces-quickpoint, text/x-co-desc, application/vnd.symbian.install, audio/x-pn-realaudio-plugin, audio/x-pn-realaudio, audio/mpegurl, audio/x-mpegurl, application/vnd.oma.dd+xml, application/x-wallet-appl.user-data-provision, application/vnd.met.ticket, application/vnd.nokia.ringing-tone, text/vnd.symbian.wml.dtd, application/vnd.wap.wbxml, application/java, video/3gp, audio/rmf, audio/x-rmf, audio/x-midi, application/x-java-archive, application/vnd.oma.drm.message, application/x-x509-ca-cert, text/plain, text/X-vCard, text/calendar, text/x-vCalendar, text/css, image/*

If that is already insane, imagine once the GW has doubled it...

The good news for Orange Spain customers is that they are not sending the customer phone number in their headers any more  (+info in Orange Spain disclosing user phone number). They now show the following HTTP header:
x-up-calling-line-id: RKWsZys5JJXXXXXXXXXXXX==

and I´ve verified that is changing every 24hours. Well done!  Also for Orange direct internet connections there seems to be no transparent proxy or if there is, the headers are not modified.


==== Vodafone Spain ===
accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
accept-charset: iso-8859-1,utf-8
accept-language: en-us,en;q=0.5
user-agent: HeaderValidator/1.1
x-up-subno: vTCMMfb8WXXXXXXXXXXXXX==
X-Forwarded-For: 213.30.40.121
Cache-Control: max-stale=0
Connection: Keep-Alive
X-BlueCoat-Via: 98586C1EE63C311A

InVodafone Spain we have another example of GW rewriting all headers to lowercase. On the other hand there is not much overhead but there is another case of unlawful user tracking. The header
x-up-subno: vTCMMfb8WXXXXXXXXXXXXX==
is fixed per user and the user is not able to remove or update it.

=== Telefonica Spain through WAP GW/Proxy ===
TM_user-id: 0342530XXXXXXXXXXXX
x-up-subno: 0342530XXXXXXXXXXXX
Connection: close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*,*/*
Accept-Charset: iso-8859-1,utf-8,*
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1 UP.Link/6.3.1.15.0
x-up-forwarded-for: 10.167.43.248
x-up-subscriber-coi: coiwap
Via: 1.1 bgui-lwp01_coi1.openwave.com:8080


=== Telefonica Spain direct INTERNET connection===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir

Telefonica Spain is also tracking its WAP users with a fixed number, without allowing them to change the id, and also without notifying them.  The "not that bad news" is that they are not using it on the Internet connection. Which means this is affecting all Symbian users but not the iPhones or Androids. There is also some unnecessary information disclosure though.  Do we need to know they have an Openwave GW Version 6.3.1.15.0? or the Subscriber "coi" whatever that is? I don´t think so.

In summary Spanish Operators like to track users and users have no way to modify this. 
Next time we´ll take a boat and see how UK is doing.
 
Posted by at No comments:

17 September 2010

Mobile operators header enrichment assessment: Part 3/6 - Germany

This time we will have a look at the mobile operators in Germany. The good news is that there are no major issues, the bad is that it made the assessment less interesting.

=== Vodafone Germany WAPGW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
Cache-Control: max-age=43200
Connection: keep-alive

=== Vodafone Germany INTERNET connection ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
Cache-Control: max-age=43200
Connection: keep-alive

The only finding in Vodafone Germany is that they use a transparent proxy for all Internet connections which probalby is the same as the WAP GW. They seam to have a caching Proxy (Cache-Control: max-age=43200) but besides that the treatment of the HTTP headers looks good.


=== O2/Telefonica Germany WAPGW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
Connection: TE, close
User-Agent: HeaderValidator/1.1
X-WAPIPADDR: 10.62.141.232

=== O2/Telefonica Germany INTERNET connection ===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir

O2 Germany does not seams to have a transparent proxy or if it has, it's not the same as the WAP one. The WAP GW slightly reorders the HTTP headers and adds one extra header. Like in the case of Vodafone Germany, no issues found.


=== TMobile Germany WAPGW/Proxy ===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir
X-Forwarded-For: 10.197.17.29
Cache-Control: max-age=4300

We can see that the TMobile Germany WAP GW is adding a couple of extra headers. Once more I would not at the X-Forwarded-For, but is not a big deal either. 


=== Eplus  WAPGW/Proxy ===
accept-language: en-us, en;q=0.5
user-agent: HeaderValidator/1.1
accept: text/html,*/*;q=0.001,image/jpeg,image/jpg,image/gif,image/png,application/octet-stream,application/java-archive,text/vnd.sun.j2me.app-descriptor,text/x-hdml,text/x-wap.wml,application/vnd.wap.xhtml+xml,application/xhtml+xml,application/vnd.wap.html+xml,text/vnd.wap.wml
accept-charset: iso-8859-1,utf-8,*;q=0.001
accept-encoding: *;q=0.001
 
=== Eplus  WAPGW/Proxy ===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir

EPlus has the most intrusive GW in Germany. It rewrites all the HTTP headers to lower case and also adds the funny qualifier q=0,001 at the end of all content related ones. If you see the last post you´ll see that the behaviour is the same like in TIM Italy wich indicates they would most probably use the same GW. On the other hand the Internet connection seams untoched. I guess their GW is busy enough!

And that was all for Germany.  Next would be Spain, which I promise it would more interesting.
Posted by at No comments:

15 September 2010

Mobile operators header enrichment assessment: Part 2/6 - Italy

This time we will have a look at how Mobile operators in Italy deal with the HTTP Header enrichment. If you have not read the previous post have a loot at Mobile operators header enrichment assessment: 1/6 - Introduction and France to understand the methodology used.

As in the case of France we use a script that sends the following HTTP headers and compares them with the ones that reach the server:

=== Original Headers ===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1


This time we are assessing the following Italian network operators: TIM, Vodafone Italy and 3 Italy (Tre Italia).
I copy below the results and in red I highlight the unexpected changes, while in orange I mark the ones that were understandable for a proxied connection.


=== TIM through WAPGW/Proxy ===
pragma: no-cache
proxy-connection: Keep-Alive
accept-language: en-us, en;q=0.5
user-agent: HeaderValidator/1.1
x-up-subno: B01-XXXXXX-XXXX820394-mic08up01_waphsp.tim.it
accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*;q=0.001
accept-charset: iso-8859-1,utf-8,*;q=0.001
accept-encoding: *;q=0.001
Connection: close
X-Adit-Lpcnt: 1


It´s interesting to see that TIM GW is modifying all the HTTP headers. First of all it is changing the case to lower case and also "q=0,001" at the end of all Accept headers and changing the order. This means that when a new HTTP request comes in, the GW will read all the HTTP headers, parse them,  change the case, reorder them and add the new sufix when relevant and create the new request. That seams to me a lot of work for a little or no gain.

Also notice the conflicting HTTP Headers:
  proxy-connection: Keep-Alive
  Connection: close 
 
It´s fair for a proxy to add the "Keep-Alive" one but it should have removed the client "Connection: close". Also I don´t understand the purpose of adding q=0.001. If the client did not want to receive some kind of content, that header might confuse the servers and make them assume that, with a really low preference, the device will accept any content.

Last but not least, check the header:
x-up-subno: B01-XXXXXX-XXXX820394-mic08up01_waphsp.tim.it
which is a constant ID that is present in all the user connections, identifying all the HTTP Requests. Although there is no direct way to relate that ID to the real identity, there is also no way for the user to erase or reset it.

=== TIM direct INTERNET connection===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir

Looking at the headers it seems that TIM does not apply any transparent proxy on their Internet connection.

=== Vodafone Italy through WAP GW/Proxy ===
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Encoding: deflate, gzip, identity
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
x-forwarded-for: 10.148.17.52
x-up-forwarded-for: 10.148.17.52
x-up-subno: g00gf1a3ffv4cfXXXXXXXXXXXXXXXXX
Via: HTTP/1.1 gmigmsp104 (XMS 724Solutions HTG XFW_002_M00_B247 20100413.142643)
Connection: keep-alive

Vodafone Italy is adding some unnecessary headers but not to the level of some of the French operators. Also, like TIM, Vodafone Italy is adding a fixed ID per user. An ID which will track the user always and that can`t be disabled.

=== 3 Italy direct INTERNET connection===
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: text/html,text/vnd.wap.wml,application/vnd.wap.html+xml,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/x-wap.wml,text/x-hdml,text/vnd.sun.j2me.app-descriptor,application/java-archive,application/octet-stream,,image/png,image/gif,image/jpg,image/jpeg,*/*
Accept-Charset: iso-8859-1,utf-8
Accept-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1-dir

3 Italy is not adding any change on the HTTP headers. Note that 3 Italy does not use any GW and thus the only way to modify the headers would need to be using a transparent proxy.

And that is all for Italy, next time we´ll have a look at the German mobile operators.
Posted by at No comments:
Subscribe to: Posts (Atom)