US Export Compliance for SSL Usage in Apps

[Benjamin Taylor]

Hello Cocoaheads,

I've previously given up on using SSL in an App due to reading about
how much of a hassle it is. I'm building a new app that definitely
needs SSL and I'm wondering what sort of approval etc I need? Most of
the stuff I've seen around the place is from 2010 and I have no idea
if this has changed, if it's required anymore or if it's even
possible.

Cheers,
- Ben

[Oliver Jones]

You should be using SSL. If you're using NSURLConnection (or CFNetworking) it should just work out of the box. Unless you're doing client side certificates that is.

There are no restrictions on using 128-bit SSL anymore AFAIK.

Regards

> --
> You received this message because you are subscribed to the Google Groups "Australian Cocoaheads" group.
> To post to this group, send email to cocoah...@googlegroups.com.
> To unsubscribe from this group, send email to cocoaheadsau...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cocoaheadsau?hl=en.
>

[Tomas Spacek]

Hi Ben,

I can't remember whether you need it or not, but if you find that you do it's not actually that much hassle: you just fill out a form on the web, wait a day or two and then you get emailed the export code you need.

Tom

[Oliver Jones]

Though now that I Google things.  Maybe you do need to certify compliance.

This blog post makes it sound pretty simple:

http://tigelane.blogspot.com.au/2011/01/apple-itunes-export-restrictions-on.html

Regards

[Ben Taylor]

I've had a look through the stuff linked from here http://stackoverflow.com/questions/2128927/using-ssl-in-an-iphone-app-export-compliance and it seems like it could take many weeks or even months for approval to go through.

However I've had a poke through App Store Review guidelines and can't see anything about SSL, Export, Encryption or HTTPS. Just hoping to find a definitive statement saying it's no longer required.

 - Ben

[Ben Taylor]

This blog post makes it sound pretty simple:

http://tigelane.blogspot.com.au/2011/01/apple-itunes-export-restrictions-on.html

A colleague has gone through this process and been rejected because he didn't have a US postal address. We're unsure if we can just provide someone else's US Postal address, or an international gateway postal address or whether this is even needed? My issue is that a lot of this information is a year and a bit old now and I can't see anything since.

 - Ben

[Jacob Rhoden]

Im a little confused, I don't think Australian citizens or companies need to comply with US laws such as us export restrictions. Even if you did, I don't think the level of encryption used with HTTPS is in breech of these restrictions.

Besides this, the https certificates issued by US companies include back doors to allow the US government to do traffic sniffing, so unless you are baking some special sort of custom encryption into your application I don't think you would be in breech anyway.

Best regards,

Jacob

[andy nicholson]

Back doors in certs?? Do you have references for this claim?

[Jacob Rhoden]

I didn't realise I need references. 

Our browsers trust anything signed by a "trusted CA" (certificate authority), or any authorised "intermediate CA".

Are you saying that it is only private corporations such as Thawte and Verisign that have the ability to sign certificates for any domain name in the world?

Best regards,

Jacob

[Ben Taylor]

I think the problem exists because the application is distributed via America and must therefore be compliant with US Export laws. Which include restrictions on encryption. It seems like it's not hard to Register for SSL Encryption, however I can't be sure if it is required or not. So for now I'm going through the process in this blog post:

http://tigelane.blogspot.com.au/2011/01/apple-itunes-export-restrictions-on.html

Minus the 1st step as you can now sign up to snap-r online (discovered by reading comments).

I figure it's best to at least know I'm trying to do the right thing, hopefully it'll save me from unexpectedly being yanked off the App Store.

If it was custom encryption that would be even tougher, fortunately all I want to use is HTTPS.

 - Ben

[andy nicholson]

I am just asking for other sources to verify your claim that https certs are broken and gov sources can read encrypted streams

[Jesse Collis]

When you say "the US Government has backdoors into your SSL Certs" you need references

[Peter Goldsmith]

Yes there are issues with SSL as a trust system as a whole, but to say there are implicit back doors is false, there are no cryptographic back doors in SSL. 

[Aidan Steele]

The implementation is not broken, it's the way the trust model has been designed. Any trusted CA (e.g. the ones included by default in iOS or OS X) can act as a man-in-the-middle and your application won't kick up a fuss. 

On Fri, Jun 1, 2012 at 1:47 PM, andy nicholson <intot...@gmail.com> wrote:

[Jacob Rhoden]

I believe my statement has been slightly mis-interpreted. Your browser trusts any certificate signed by any "trusted CA" or any authorised "intermediate CA".

If  (for example) your HTTPS connection is redirected through a router that has the ability to issue certificates on the fly from a "trusted CA" or an "intermediate CA", there is no way of knowing (except for the fact the certificate itself will look different).

[snare]

I don't think it has really been misinterpreted. You are suggesting that the US government has access to the CA (signing) certificate private keys for all major US Certificate Authorities, and that some proxy devices exist at strategic points around the internet under the US government's control which contain all these CA certs and generate certificates on-the-fly to man-in-the-middle all SSL traffic that passes through them. Is that about right? So you may want to provide some evidence of this conspiracy theory. It's not an uncommon theory, but it's certainly not commonly accepted as fact.

As to your previous question - anybody can sign a certificate for any domain name on the internet. That doesn't mean that certificate is trusted by the client endpoint. It will only trust certificates signed by CA's that are marked as trusted in its certificate store - so, yes, companies like Thawte, Verisign, etc. These companies generally protect their CA keys pretty well. There was an incident not too long ago in which a CA trusted by most OSs & browsers, DigiNotar, was compromised and fake wildcard certificates were generated for Google/GMail/etc in order to man-in-the-middle SSL traffic to GMail from with Iran.

As Aidan said, this is the way the trust model has been designed. It is pretty bad, but it's not so broken that any proxy can MITM SSL traffic without the user noticing.

Loukas

[Jacob Rhoden]

On Jun 1, 2012, at 12:24 PM, snare wrote:

> I don't think it has really been misinterpreted. You are suggesting that the US government has access to the CA (signing) certificate private keys for all major US Certificate Authorities

Ever heard of a "National security letter"? A company can be compelled to hand over something along with criminal penalties for telling anyone that the data was handed over.

> and that some proxy devices exist at strategic points around the internet under the US government's control which contain all these CA certs and generate certificates on-the-fly to man-in-the-middle all SSL traffic that passes through them.

Your naive if you don't think that this ability exists.

> As Aidan said, this is the way the trust model has been designed. It is pretty bad, but it's not so broken that any proxy can MITM SSL traffic without the user noticing.

Yes it is that bad, a site can change IP address and certificate and your browser will not warn you. There is no way to know that your data might be going to a different location unless you manually check a sites certificate.

[Jacob Rhoden]

It's been a while since I looked this stuff up, even google can now issue trusted certificates? Interesting stuff:

security researchers have uncovered more than 600 groups who, through such delegation, are now also automatically trusted by most browsers, including the Department of Homeland Security, Google, and Ford Motors­and a UAE mobile phone company called Etisalat.

http://www.schneier.com/blog/archives/2010/09/uae_man-in-the-.html

[snare]

> Ever heard of a "National security letter"? A company can be compelled to hand over something along with criminal penalties for telling anyone that the data was handed over.

> ...

> Your naive if you don't think that this ability exists.

It wouldn't surprise me, but it's not commonly accepted fact.

> Yes it is that bad, a site can change IP address and certificate and your browser will not warn you. There is no way to know that your data might be going to a different location unless you manually check a sites certificate.

A site can probably change IP address since the certificate is assigned to a domain name, but this would require a DNS compromise and the ability to sign certificates. It could change certificate without the browser warning you, again, only if the new certificate was signed by a trusted CA. Both very low likelihood IMHO, though the DigiNotar incident demonstrates that it's a real possibility.

I'm not saying that it's not bad - as Peter said, it has plenty of problems - just that it's not possible for an arbitrary proxy to MITM SSL. I can't just go and set up a proxy to MITM SSL, I need the keys for a trusted CA.

[andy nicholson]

Now that's a reference :)
I accept that's its possible but like snare mentioned do they have all the signing keys for all private CAs? 
Can we have a crowd based system of mitm monitoring please??

[Jacob Rhoden]

Now that's a reference :)
I accept that's its possible but like snare mentioned do they have all the signing keys for all private CAs?  
Can we have a crowd based system of mitm monitoring please?? 

The problem is they don't need signing keys for all private CA's, just one.  If on day one you try to read your google mail and the cert is verisign, and on day two the cert changes to homeland security or even just a different verisign "trusted CA" you wouldn't know.

On Jun 1, 2012, at 12:52 PM, snare wrote:

Yes it is that bad, a site can change IP address and certificate and your browser will not warn you. There is no way to know that your data might be going to a different location unless you manually check a sites certificate.

A site can probably change IP address since the certificate is assigned to a domain name, but this would require a DNS compromise and the ability to sign certificates. It could change certificate without the browser warning you, again, only if the new certificate was signed by a trusted CA. Both very low likelihood IMHO, though the DigiNotar incident demonstrates that it's a real possibility.

I going to try to avoid replying due to the off topic nature of this thread but I feel the need to correct something.

You don't need a DNS compromise to intercept traffic. Anyone with access to a physical network device through which your data is flowing has the ability to read your traffic, and re-route to a different server claiming to be the server you think you should be talking to. 

[Aidan Steele]

The EFF SSL Observatory is waaaay ahead of you. :-)

[1]: https://www.eff.org/observatory

[snare]

Also worth checking out Moxie Marlinspike's "Convergence" project which has been designed to address the problems in the SSL trust model.

http://convergence.io/

Not so useful for iOS though :(

[Jerrold Poh]

Hi Ben, I literally went through this process a couple of weeks ago, as my app uses SSL to communicate with the server component.

It's actually not as painful as it sounds, and I manage to do it all in a Sunday afternoon.  I just followed the instructions below, got my SNAP-R account after a 30 minute wait, and got an ERN right after I submitted the form.

http://tigelane.blogspot.com.au/2011/01/apple-itunes-export-restrictions-on.html 

From what I understand, you have to do this even though you're not based in the US, and as far as I know, you don't need a US postal address either (well I didn't and I was approved without any problems).  

Consequently though, I was talking to Loren Brichter (*squeel*) about this at the One More Thing conference last week (so I assume it's correct), and he said that you no longer have to do this if you're just using the standard SSL libraries (as confirmed by Oliver too).

To be honest, I'd apply for an ERN anyway.  It takes a couple of hours, but it could potentially save you the back and forth you may encounter later.

Hopefully that was helpful, good luck!

Jerrold

[Ben Taylor]

Thanks Jerrold. I've started the application process, so we'll see.

 - Ben

On Friday, 1 June 2012 at 3:49 PM, Jerrold Poh wrote:

Hi, I literally went through this process a couple of weeks ago, as my app uses SSL to communicate with the server component.

I followed the instructions below on a Sunday afternoon, got my SNAP-R account after a 30 minute wait, and  got an ERN right after I submitted the form.

http://tigelane.blogspot.com.au/2011/01/apple-itunes-export-restrictions-on.html 

From what I understand, you have to do this even though you're not an Australian citizen, and as far as I know, you don't don't a US postal address either to set it up (well I didn't and I was approved without issue).  

Consequently though, I was talking to Loren Brichter about this at the One More Thing conference last week (so I assume it's correct), and he said me that you no longer have to do this if you're just using the standard SSL libraries (as confirmed by Oliver too).

To be honest, I'd apply for an ERN anyway.  It takes a couple of hours to do but it could potentially save you the back and forth that you may encounter later.

Jerrold

On Friday, June 1, 2012 11:09:58 AM UTC+10, Benjamin Taylor wrote:

On Friday, June 1, 2012 11:09:58 AM UTC+10, Benjamin Taylor wrote:

On Friday, June 1, 2012 11:09:58 AM UTC+10, Benjamin Taylor wrote:

--

You received this message because you are subscribed to the Google Groups "Australian Cocoaheads" group.

To view this discussion on the web visit https://groups.google.com/d/msg/cocoaheadsau/-/UNxNFRIWckcJ.

[Matt Connolly]

On 01/06/2012, at 11:09 AM, Benjamin Taylor wrote:

> Hello Cocoaheads,
>
> I've previously given up on using SSL in an App due to reading about
> how much of a hassle it is. I'm building a new app that definitely
> needs SSL and I'm wondering what sort of approval etc I need? Most of
> the stuff I've seen around the place is from 2010 and I have no idea
> if this has changed, if it's required anymore or if it's even
> possible.

Hi Ben,

It's also worth looking at the allowed exceptions. And worth reading the US government info about it here:

http://www.bis.doc.gov/encryption/default.htm


From my interpretation (i am not a lawyer) these two cases allow use of encryption and qualify for an exception so you don't need to do the ERN filing:

1. (from flow chart 1 (follow above link):
"Is the encryption functionality limited to intellectual property or copyright protection functions?" -> not covered by Cat 5 Part 2.

2. From flowchart 2 (follow above link - decision tree):
"If encryption is used for authentication only, then no ERN is required. (See working in Cat5 part 2 under section 5A002.a.1)
-> Self Classify -> no ERN required


We recently updated an app to declare that it used encryption and qualified for the listed exemptions and therefore required no ERN. It's been on the app-store for months now. (Our decision to go for the exception was based on the fact that the encryption was only used during transport of data to protect the user's intellectual property in that data.)


The other aspect that I find interesting is that when using HTTPS encryption was controlled by the SERVER. That is, the SSL certificates are configured on the server and the client will use ssl encryption (after accepting trust, etc) according to the server's certificate and configuration.

So when the compliance rules say you must declare if you are using more than 128-bit encryption, the app itself actually has no knowledge of the server's certificate, and the server may change its certificate at any time without any changes to your app.

Another annoying note from the question 2 page (follow link above):

"Similarly, if the item includes encryption functionality, even if the encryption functionality is not used by the item, then BIS evaluates the item based on the included encryption functionality."

This could be interpreted as every app needing to be qualified because the iPhone has a library that supports encryption, even if you don't use it. Whatever.

It'd be nice if Apple could set up an iTunes store outside the US so we didn't have to "export" the app from the US!!!


-Matt

[Raymond Hodgson]

This entire conspiracy line doesn't make sense. If the US gov't had
all of these keys as you say, they wouldn't need or want to put
restrictions on crypto as they would want people to use the crypto
they already have the key for. More to the point, it would be illegal
for the gov't to arbitrarily read traffic of US citizens, and it would
cause a major diplomatic issue with every gov't in the world if they
were to engage in such broad scale spying. Even having such a back
door would not be worth the backlash it would cause.

It would also be rather pointless since, if SSL were compromised and
you were worrying about someone reading your data, the obvious
solution would be to switch to a different public key system that
can't be broken. Which would be the kind of crypto systems that are
actually covered by the export ban.

> Ever heard of a "National security letter"? A company can be compelled to hand over something along with criminal penalties for telling anyone that the data was handed over.

These only apply to US citizens or companies in the US, and they still
have to go through a judge where they have to show they are related to
national security issues. They are less restrictive than previous laws
but not a broad license to engage in spying. And they never will be
for reasons mentioned in the first paragraph.

The bottom line is SSL works great to protect against criminals
stealing your data over the network, which is what it was designed to
do. Just because it may not be good enough to defeat the NSA doesn't
mean the NSA has a system in place to read everyone's SSL traffic or
that you should worry about them acquiring that ability any time soon.