14 August 2011

Access Local Machine certificates without Admin rights

Digital certificates in windows, either the end entitty certificates, called Personal Certificates, the subCAs or the Root CAs, are stored in the so called Certificate Stores. There are different types of Certificate Stores but the more relevant ones are:



• Personal CA Store: Certificates, either end entities, subCAs or Root CAs, that apply to the current user

• Local Machine CA Store: Certificates, either end entities, subCAs or Root CAs, that apply to the system account. These apply to the user too. This means that a certificate issued by a Root CA available in the Local Machine CA Store but missing in the Personal CA Store would be treated as a valid.


In order to have access to the digital certificates used by Windows and integrated applications you need to follow these steps: (Have in mind that Firefox uses its own digital certificate stores).


From the command line open an MMC:

 


In the MMC add the Certificate snap-in




If you have local machine admin rights you have the right to choose the CA Store you want to open, if not it will automatically open the Personal CA Store

 
 
 
The naming can be a bit confusing but you should concentrate in the following folders:

• Personal: These are the end entity certificates assigned to the account (User or System)
• Trusted Root Certification Authorities: The Root CAs
• Intermediate Certificate Authorities: The subCAs

From the Certificate console, you are able to browse, add, delete all different types of certificates. If you need information of the other folders you can check the Microsoft article https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_cmuncertstor.mspx .

 
As said, if the user does not have admin rights he won´t be allowed to choose the “Computer account” where the certificates that apply to the System account are stored. Something that creates a bit of confusion is the fact that the Root CAs and subCAs from that store apply to the current user. Unfortunately these can only be examined by the end user in case his account has local admin machine rights. Although it’s understandable that a restricted user should not be available to apply changes that will affect all users, it makes no sense that it is not allowed to list the complete list of Root CAs available in the System account and that will be trusted in any SSL connection he establishes.

The good news is that the restrictions to access the Local Machine CA Store are rather weak and I just found a quick workaround for this.

From a computer where you have admin rights perform the steps above and repeat them adding the Computer Account. You should have a console with entries to the user and system accounts:

 
 
Go to "File -> Save as" and save the console (with extension msc) in a known directory. Transfer the file using a USB disk or by email to the target computer and you will be able to access the “restricted” Local Machine Store even if the logged user does not have local admin rights.


This is a simple hack but very useful when troubleshooting certificate related problems when users have restricted accounts. I have tested in a Windows 7, if you test it in other platforms let me know the results.

I  just hope that the rest of the Windows 7 access control mechanisms are more robust than this!
Posted by at 2 comments:
Labels: ,

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 5 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 2 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:
Subscribe to: Posts (Atom)