RE: ACTION-893: Start putting together a set of guidelines that could help address the security issues triggered by links rewriting.

The payment card industry (PCI) has data security standards (DSS) [1] that apply to the transmission and processing of credit card data, including the passage of that data through secure channels such as SSL-protected connections. The providers of any processing component in this pathway are obliged to be PCI DSS compliant in order for the entire process to be deemed compliant. Thus it would appear that the introduction of a man-in-the-middle would only be compliant if it was a formal part of the delivery path and it was also PCI DSS compliant. Adapting the front-end of a credit card payment process/interface is not a passive step in the delivery, given that the adaptation would involve access to credit card data. Therefore to be compliant with PCI DSS, the provider of the intermediate adaptation process would have to comply with the PCI DSS requirements regarding the handling of credit card information, the handling of logs, the layers of access control for their environment, the quarterly and annual security audits etc.

In the absence of any visible declaration of compliance with PCI DSS, I can only assume that intermediaries that are intercepting SSL (HTTPS) traffic are introducing a component of non-compliance in the delivery path, and that any vendor intent on retaining their status as a PCI DSS compliant vendor will have to take steps to avoid any delivery paths where this threat is known to be present. This could see vendors avoiding delivery via certain operators, to certain devices, to proxy-based browsers and so on. At worst, it might see vendors avoid mobile completely, until they find something to replace SSL/HTTPS that cannot be intercepted.

I have practical experience with these matters. Intermediate traffic interception is a serious concern for the e-payment industry, regardless of the motivation for their presence.

---Rotan.

[1] https://www.pcisecuritystandards.org/




From: Luca Passani
Sent: Sun 18/01/2009 16:12
To: Mobile Web Best Practices Working Group WG
Subject: Re: ACTION-893: Start putting together a set of guidelines that could   help address the security issues triggered by links rewriting.


David Storey wrote:
>>
>> I think they are both wrong. But since OperaMini tends to be "opt-in" 
>> by nature, it does not bother the rest of the ecosystem as much as 
>> the others. FYI, Opera partnered with ByteMobile, which leverages 
>> Opera's technology to reformat websites exactly as Novarra and all 
>> the others (look at Voda Ireland, for example). Glad to hear that 
>> Opera does not like this model.
>
> "I" and "Opera" are not exactly the same thing.  I don't doubt it is a 
> solution to a problem, especially when the transcoders are good quality.

Noted. For those who wonder what we are talking about:

http://www.opera.com/press/releases/2007/02/06/

>>>
>>> In regard to the no transform header; this can't work for solutions 
>>> such as Opera Mini, where they only support using a proxy.
>>
>> I think OperaMini should stop transcoding HTTPS content
>
> Wouldn't work.  Opera Mini only supports transcoded content.  Without 
> it we'd have to show a screen saying "site not supported"  Not exactly 
> good user experience, or what the user wants.

right. Not a good user experience. But totally against what the content 
owner may want. If I make the effort to create an HTTPS site, it may 
well mean that I don't want anyone to interfere in the communication 
between me and the client, don't you think?

After all, also waiting in line is not a good user-experience. Users 
have the right to complain about the long wait, or just vote with their 
feet and go somewhere else. They do not have the right to walk behind 
the counter and help themselves (i.e. break HTTPS).

>   If a browser supports both regular html and transcoded content then 
> I personally fully agree, but otherwise we need to serve the content.

again, you don't need to. You want to. And you do it with the hope that 
nobody gets seriously mad at what you are doing.

>
> Opera Mini exists to run on phones that wouldn't support a full 
> browser.  Users do also run it on smart phones as it saves the user 
> money in data traffic (and assumably the operator in data traffic costs).

well, operators make money on data traffic, but let's not go there, it 
would be a digression.

Luca