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.

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.
 

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.
 

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.

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.

Mobile operators header enrichment assement: 1/6 - Introduction and France

During the last weeks I have been assessing how Mobile operators mangle HTTP connections and today I start a series of posts to present the results.

One of the main differences between mobile and fixed operators is that the first have been providing the so called Valued Added Services (VAS), while the second, in most cases, are just fat pipes. The main VAS enablers are the former Wireless Application Protocol Gateways (WAP  GW).

Ten years ago, WAP GW had the important role to convert the efficient and compact WTP/WSP to the standard and broadly used TCP/HTTP.  Nowadays, when all (relevant) devices support WAP2.0, WAP GW are not much different from any enterprise Proxy. The main difference is that in order to support the VAS, WAP GW enrich the HTTP headers. There are different flavors of header enrichment: on one hand the most common behavior includes adding a user ID, like the mobile phone (MSISDN) for dedicated internal services allowing the VAS to identify the user, and most probably charge him/her. On the other, some operators would modify the HTTP headers for different reasons. Also some others would add extra information like bearer type, Proxy ID, device real IP, etc.

The methodology for the tests is simple. I have several GPRS/UMTS modems with the SIM cards of the operators that I want to analyse. I created a script that would initiate a connection through a given modem from one of the mobile operators and access a server I own that replies with the HTTP headers that reached the server. As I know the headers I input and the ones that reach the server I can compare them and note the results.

When doing the connection to the operator I do it in two ways. First I would use the so called WAP connection and connect trough the WAP GW. In this case I´m simulating a standard mobile phone like most Nokia, Motorola, Samsung, Sony Ericcson.... In the second connection I would use the so called WEB or INTERNET connection, simulating an Android, iPhone or standard PC with a data card. Although most people think that in the second case the user is accessing the internet directly, without going through a proxy we will see that it is not the case. Since the advent of the Androids and iPhones, which do not support an operator proxy, mobile operators have deployed transparent proxies (aka intercepting proxies)  on the "Internet" connection, forcing also these devices to go trough them.

Having said that, lets take a look at some real examples from the french mobile operators: Orange, SFR and Bouygues. First of all, these are the original headers of my script:

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

whereas when using the direct connection the headers were the same but the User Agent was:
User-Agent: HeaderValidator/1.1-dir

Below I add the headers as received in the server for the different connections. In red I highlight the unexpected changes, while in orange I marked the ones that where understandable for a proxied connection.

=== Orange France 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-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
X-Nokia-CONNECTION_MODE: TCP
X-NSN-PROTOCOL-TYPE: WAP2.0
X-Nokia-BEARER: GPRS
X-Nokia-PLTF: NBG3.1.3_PP
X-Wisp: wisp2
Via: 1.1, 1.1 proxy (proxy)
Cache-Control: max-age=259200
Connection: keep-alive

=== Orange France direct connection (INTERNET) ===
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-Wisp: wisp2
Via: 1.1 proxy (proxy)
Cache-Control: max-age=259200
Connection: keep-alive

=== SFR 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-Language: en-us,en;q=0.5
User-Agent: HeaderValidator/1.1
X-vfprovider: SFR
X-vfstatus: 10
X-Nokia-BEARER: GPRS
serviceControlInfo: 18+=-
x-nokia-gid: 259107281784650
X-Nokia-CONNECTION_MODE: TCP
X-Nokia-gateway-id: NWG/4.1/Build79
X-Nokia-ipaddress: 10.187.207.132
Via: 1.1 proxy.cwg.net (proxy)
X-Forwarded-For: 10.187.207.132, 10.187.207.132
Cache-Control: max-age=259200
Connection: Keep-Alive
Pragma: no-cache
X-BlueCoat-Via: 28409D05D072730C

=== SFR direct connection (INTERNET) ===
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-vfprovider: SFR
X-vfstatus: 10
X-Nokia-BEARER: GPRS
serviceControlInfo: 18+=-
x-nokia-gid: 259107281784650
X-Nokia-CONNECTION_MODE: TCP
X-Nokia-gateway-id: NWG/4.1/Build79
X-Nokia-ipaddress: 10.205.32.74
Via: 1.1 proxy.cwg.net (proxy)
X-Forwarded-For: 10.205.32.74, 10.205.32.74
Cache-Control: max-age=259200
Connection: Keep-Alive
Pragma: no-cache
X-BlueCoat-Via: DFF4C47D046B9013

=== Bouygues through WAP GW/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
Host: m.mobiclip.net
User-Agent: HeaderValidator/1.1

=== Bouygues direct connection (INTERNET) ===
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

In France we can see there is one operator, Bouygues that preservers the HTTP headers intact, probably having a better performance than SFR and Orange which add a lot of useless information.

Looking at the "new" headers added by Orange and SFR, the first question that arises is, do we really need to know the information below? What for?

X-NSN-PROTOCOL-TYPE: WAP2.0
X-Nokia-PLTF: NBG3.1.3_PP
X-Wisp: wisp2
Via: 1.1, 1.1 proxy (proxy)
X-vfprovider: SFR
X-vfstatus: 10
x-nokia-gid: 259107281784650
X-Nokia-CONNECTION_MODE: TCP
X-Nokia-gateway-id: NWG/4.1/Build79
X-Nokia-ipaddress: 10.205.32.74
Via: 1.1 proxy.cwg.net (proxy)
X-Forwarded-For: 10.205.32.74, 10.205.32.74
X-BlueCoat-Via: DFF4C47D046B9013


What is the purpose of wasting GW memory and CPU cycles adding this? Do we really need to know our device uses WAP2.0 or TCP? Or the Nokia GW ID or the Blue-Coat proxy ID? What for? As we will see in the future posts the variety of data across the main mobile operators is so big that we can conclude that this HTTP noise can´t be of use for anyone.


The surprising part is that, especially in the case of SFR, all the headers are also added by the transparent proxy in Internet connection. While in the case of Orange we see that the number of headers has been dramatically reduced.

I would assume that SFR is adding the transparent proxy "in front" of the standard Nokia GW, routing all Internet connections through it and later through the BlueCoat. Good for Nokia, as that sounds like they would need a lot of HW and licenses!!. While Orange France seams to follow a more sensible approach redirecting the Internet connections to the "WISP2" proxy which might be in charge of the useful header enrichment.

That´s all for now. Next time we´ll have a look at how the Italian Mobile Operators deal with the header enrichment.

Android embeded certificates

Testing an application I wanted to verify the Root CAs embedded in an Android phone. After some searches the procedure has been easier than suspected. (For this test I used a WinXP SP3 with Java version 1.6.0_13). This what you should do to repeat it:

1) Install the Android USB Driver:
Download the Android SDK Starter package at http://developer.android.com/sdk/index.html, execute it, uncheck al components and mark the "USB Drives". Now you should have a new folder called "usb_driver"

2) In your Android phone go to Settings => Applications => Development and check "USB Debugging"

3) Connect the phone to the computer and when requested to install the required drivers choose the folder "usb_driver"

4) Go to the folder tools and in a console run
adb devices
That should display the serial number of the device you have connected. If that fails unplug and plug the device (you are in a Windows box my friend!)
5) Run
adb pull /system/etc/security/cacerts.bks cacerts.bks
to get the Root CA keystore in your computer
6) To be able to deal with that keystore you need the jar http://bouncycastle.org/download/bcprov-jdk16-141.jar on $JAVA_HOME/jre/lib/ext/
Now you can just run:
keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -list -v
to display the installed Root CAs

If you want to skip it I copy below the ones I found in the Nexus One and Magic:

Nexus One Root CAs:
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority
Issuer: C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority - G2,OU=(c) 1998 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust Network
Issuer: C=IL,O=StartCom Ltd.,OU=StartCom Certification Authority,CN=StartCom Extended Validation Server CA
Issuer: C=PL,O=Unizeto Sp. z o.o.,CN=Certum CA
Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert Assured ID Root CA
Issuer: C=HU,L=Budapest,O=NetLock Halozatbiztonsagi Kft.,OU=Tanusitvanykiadok,CN=NetLock Expressz (Class C) Tanusitvanykiado
Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware
Issuer: C=BM,O=QuoVadis Limited,OU=Root Certification Authority,CN=QuoVadis Root Certification Authority
Issuer: C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5
Issuer: C=HU,L=Budapest,O=NetLock Halozatbiztonsagi Kft.,OU=Tanusitvanykiadok,CN=NetLock Uzleti (Class B) Tanusitvanykiado
Issuer: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 1 Policy Validation Authority,CN=http://www.valicert.com/,E=info@valicert.com
Issuer: C=US,O=Equifax,OU=Equifax Secure Certificate Authority
Issuer: C=EU,O=AC Camerfirma SA CIF A82743287,OU=http://www.chambersign.org,CN=Chambers of Commerce Root
Issuer: C=US,O=Entrust.net,OU=www.entrust.net/CPS incorp. by ref. (limits liab.),OU=(c) 1999 Entrust.net Limited,CN=Entrust.net Secure Server Certification Authority
Issuer: C=US,O=Equifax Secure Inc.,CN=Equifax Secure eBusiness CA-1
Issuer: C=DE,ST=Hamburg,L=Hamburg,O=TC TrustCenter for Security in Data Networks GmbH,OU=TC TrustCenter Class 2 CA,E=certificate@trustcenter.de
Issuer: C=US,O=Starfield Technologies\, Inc.,OU=Starfield Class 2 Certification Authority
Issuer: C=DE,ST=Hamburg,L=Hamburg,O=TC TrustCenter for Security in Data Networks GmbH,OU=TC TrustCenter Class 3 CA,E=certificate@trustcenter.de
Issuer: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority
Issuer: C=DE,O=TC TrustCenter GmbH,OU=TC TrustCenter Universal CA,CN=TC TrustCenter Universal CA I
Issuer: C=TW,O=Government Root Certification Authority
Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN - DATACorp SGC
Issuer: C=ch,O=Swisscom,OU=Digital Certificate Services,CN=Swisscom Root CA 1
Issuer: C=ES,O=FNMT,OU=FNMT Clase 2 CA
Issuer: C=DE,O=Deutsche Telekom AG,OU=T-TeleSec Trust Center,CN=Deutsche Telekom Root CA 2
Issuer: C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Server CA,E=server-certs@thawte.com
Issuer: C=US,O=Digital Signature Trust,OU=DST ACES,CN=DST ACES CA X6
Issuer: C=US,O=GTE Corporation,OU=GTE CyberTrust Solutions\, Inc.,CN=GTE CyberTrust Global Root
Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Network Applications
Issuer: C=FR,O=Certplus,CN=Class 2 Primary CA
Issuer: O=Entrust.net,OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),OU=(c) 1999 Entrust.net Limited,CN=Entrust.net Certification Authority (2048)
Issuer: C=JP,O=Japan Certification Services\, Inc.,CN=SecureSign RootCA1
Issuer: C=DK,O=TDC Internet,OU=TDC Internet Root CA
Issuer: C=ES,L=C/ Muntaner 244 Barcelona,CN=Autoridad de Certificacion Firmaprofesional CIF A62634068,E=ca@firmaprofesional.com
Issuer: C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root
Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert Global Root CA
Issuer: OU=GlobalSign Root CA - R2,O=GlobalSign,CN=GlobalSign
Issuer: C=NL,O=Staat der Nederlanden,CN=Staat der Nederlanden Root CA
Issuer: C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,E=premium-server@thawte.com
Issuer: OU=Copyright (c) 1997 Microsoft Corp.,OU=Microsoft Corporation,CN=Microsoft Root Authority
Issuer: C=IL,O=StartCom Ltd.,OU=Secure Digital Certificate Signing,CN=StartCom Certification Authority
Issuer: C=US,O=Entrust\, Inc.,OU=www.entrust.net/CPS is incorporated by reference,OU=(c) 2006 Entrust\, Inc.,CN=Entrust Root Certification Authority
Issuer: C=DE,O=TC TrustCenter GmbH,OU=TC TrustCenter Class 2 CA,CN=TC TrustCenter Class 2 CA II
Issuer: C=US,O=America Online Inc.,CN=America Online Root Certification Authority 1
Issuer: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 2 Policy Validation Authority,CN=http://www.valicert.com/,E=info@valicert.com
Issuer: C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)06,CN=VeriSign Class 3 Extended Validation SSL SGC CA
Issuer: C=BE,O=GlobalSign nv-sa,OU=Root CA,CN=GlobalSign Root CA
Issuer: C=HU,ST=Hungary,L=Budapest,O=NetLock Halozatbiztonsagi Kft.,OU=Tanusitvanykiadok,CN=NetLock Kozjegyzoi (Class A) Tanusitvanykiado
Issuer: C=US,O=Entrust\, Inc.,OU=AND ADDITIONAL TERMS GOVERNING USE AND RELIANCE,OU=CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND LIABILITY,OU=www.entrust.net/CPS is incorporated by reference,OU=(c) 2008 Entrust\, Inc.,CN=Entrust Certification Authority - L1B
Issuer: C=FI,O=Sonera,CN=Sonera Class2 CA
Issuer: C=JP,O=SECOM Trust.net,OU=Security Communication RootCA1
Issuer: C=BM,O=QuoVadis Limited,CN=QuoVadis Root CA 3
Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV Root CA
Issuer: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 3 Policy Validation Authority,CN=http://www.valicert.com/,E=info@valicert.com
Issuer: C=BM,O=QuoVadis Limited,CN=QuoVadis Root CA 2

Magic:
Issuer: C=HU,ST=Hungary,L=Budapest,O=NetLock Halozatbiztonsagi Kft.,OU=Tanusitvanykiadok,CN=NetLock Kozjegyzoi (Class A) Tanusitvanykiado
Issuer: C=FI,O=Sonera,CN=Sonera Class2 CA
Issuer: C=JP,O=SECOM Trust.net,OU=Security Communication RootCA1
Issuer: C=US,O=GTE Corporation,CN=GTE CyberTrust Root
Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV Root CA
Issuer: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 3 Policy Validation Authority,CN=http://www.valicert.com/,E=info@valicert.com
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority
Issuer: C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority - G2,OU=(c) 1998 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust Network
Issuer: C=PL,O=Unizeto Sp. z o.o.,CN=Certum CA
Issuer: C=DE,ST=Hamburg,L=Hamburg,O=TC TrustCenter for Security in Data Networks GmbH,OU=TC TrustCenter Class 2 CA,E=certificate@trustcenter.de
Issuer: C=US,O=Starfield Technologies\, Inc.,OU=Starfield Class 2 Certification Authority
Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert Assured ID Root CA
Issuer: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority
Issuer: C=HU,L=Budapest,O=NetLock Halozatbiztonsagi Kft.,OU=Tanusitvanykiadok,CN=NetLock Expressz (Class C) Tanusitvanykiado
Issuer: C=TW,O=Government Root Certification Authority
Issuer: C=HU,L=Budapest,O=NetLock Halozatbiztonsagi Kft.,OU=Tanusitvanykiadok,CN=NetLock Uzleti (Class B) Tanusitvanykiado
Issuer: C=ES,O=FNMT,OU=FNMT Clase 2 CA
Issuer: C=US,O=Equifax,OU=Equifax Secure Certificate Authority
Issuer: C=US,O=Digital Signature Trust,OU=DST ACES,CN=DST ACES CA X6
Issuer: C=DE,ST=Hamburg,L=Hamburg,O=TC TrustCenter for Security in Data Networks GmbH,OU=TC TrustCenter Class 3 CA,E=certificate@trustcenter.de
Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware
Issuer: C=FR,O=Certplus,CN=Class 2 Primary CA
Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN - DATACorp SGC
Issuer: C=US,O=RSA Data Security\, Inc.,OU=Secure Server Certification Authority
Issuer: C=ES,L=C/ Muntaner 244 Barcelona,CN=Autoridad de Certificacion Firmaprofesional CIF A62634068,E=ca@firmaprofesional.com
Issuer: C=DE,O=Deutsche Telekom AG,OU=T-TeleSec Trust Center,CN=Deutsche Telekom Root CA 2
Issuer: C=ES,ST=BARCELONA,L=BARCELONA,O=IPS Seguridad CA,OU=Certificaciones,CN=IPS SERVIDORES,E=ips@mail.ips.es
Issuer: OU=GlobalSign Root CA - R2,O=GlobalSign,CN=GlobalSign
Issuer: C=US,O=GTE Corporation,OU=GTE CyberTrust Solutions\, Inc.,CN=GTE CyberTrust Global Root
Issuer: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 1 Policy Validation Authority,CN=http://www.valicert.com/,E=info@valicert.com
Issuer: OU=Copyright (c) 1997 Microsoft Corp.,OU=Microsoft Corporation,CN=Microsoft Root Authority
Issuer: C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root
Issuer: C=EU,O=AC Camerfirma SA CIF A82743287,OU=http://www.chambersign.org,CN=Chambers of Commerce Root
Issuer: C=US,O=Entrust.net,OU=www.entrust.net/CPS incorp. by ref. (limits liab.),OU=(c) 1999 Entrust.net Limited,CN=Entrust.net Secure Server Certification Authority
Issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert Global Root CA
Issuer: C=US,O=Equifax Secure Inc.,CN=Equifax Secure eBusiness CA-1
Issuer: C=ch,O=Swisscom,OU=Digital Certificate Services,CN=Swisscom Root CA 1
Issuer: C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Server CA,E=server-certs@thawte.com
Issuer: C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Network Applications
Issuer: C=JP,O=Japan Certification Services\, Inc.,CN=SecureSign RootCA1
Issuer: C=DK,O=TDC Internet,OU=TDC Internet Root CA
Issuer: C=NL,O=Staat der Nederlanden,CN=Staat der Nederlanden Root CA
Issuer: C=IL,ST=Israel,L=Eilat,O=StartCom Ltd.,OU=CA Authority Dep.,CN=Free SSL Certification Authority,E=admin@startcom.org
Issuer: C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,E=premium-server@thawte.com
Issuer: C=US,O=America Online Inc.,CN=America Online Root Certification Authority 1
Issuer: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 2 Policy Validation Authority,CN=http://www.valicert.com/,E=info@valicert.com
Issuer: C=BE,O=GlobalSign nv-sa,OU=Root CA,CN=GlobalSign Root CA


Main sources:
http://wiki.cacert.org/ImportRootCert#Android_Phones
http://developer.android.com/sdk/index.html

Orange Spain privacy misconfiguration fixed!

I`m just being informed by"Anonymous" that the issue with the headers in Orange Spain has been fixed. I copy below a recent trace where the MSISDN is not being added anymore:

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: {REMOVED}
X-Forwarded-For: 213.30.40.121
Cache-Control: max-stale=0
Connection: Keep-Alive
X-BlueCoat-Via: 4A19C93B98112ACC

I see they also removed some unnecessary headers (more on this in a future post)
The Full Disclosure Mailing List and twitter managed to caught their attention.
Another example that responsible disclosure is not always enough.