I can't find a definitive answer on this, but a the moment I'm guessing not. If not, is there any possible workaround other than proxying via a server?
By way of interest, I'm just trying to connect to Gmail imap for a small test application...
No, WP7.1 does not support SSL sockets.
Edit
Typically you would use SslStream to implement SSL over TCP. Unfortunately, SslStream is not available in Silverlight or WP7. You have to roll your own (which is a bad idea, but possible), or use a third party library.
As mentioned by Eugene, there's SecureBlackbox, but that's more than a thousand dollars (minimum, depending on your many license choices) to use in a commercial product. If you're doing this on your own, that's probably too big an upfront cost. If you're doing this for your company, it might be a route to consider.
Another option might be to try to use BouncyCastle in WP7, however BouncyCastle doesn't currently release WP7 compatible binaries and may rely on framework items not available in WP7. This blog entry implies it might be possible, but will require some tweaking.
If you're a solo dev, I'd recommend at least trying BouncyCastle before considering SecureBlackbox. If you're doing your company's WP7 app offering, start with SecureBlackbox.
Our SecureBlackbox offers SSL support: you can use SSL engine with any transport (including sockets and pigeon mail) or you can use socket-based client component. There's a WP7-specific problem with certificate validation though - as WP7 doesn't let us access system certificates, you would need to have trusted certificates list in your application. Not a big problem with our components (SecureBlackbox includes complete certificate management as well), but you need to be aware about this extra step.
As far as I know, IPWorks by /n Software is offered for Windows Phone Mango, but I don't know exactly what they offer in SSL aspect.
I did get Bouncy Castle compiling for CF 3.5 - it's probably not a stretch to use that work for Windows Phone.
Internally we've been using an internal port of OpenSSL for Compact Framework apps for ages, and it wasn't a difficult port. I suspect getting that working under Phone also wouldn't be overly difficult.
Related
I have a long time setup which is capturing and decrypting HTTPS using Fiddler Proxy, I use my jailbroken phone so I can go around certificate pinning also and run it thru this proxy to capture traffic and analyze request/responses for different apps. I love Fiddler because it allows me to modify content on the fly at will to find issues. Today I ran into an app that is not behaving nicely and after some hours of research it seems my issue is because the app is using HTTP/3 and I haven't been able to make it work. Am I just barking at the wrong tree here? Is it even possible to capture such traffic with Fiddler Proxy? any alternatives with same like features that I could use? I'm not expert on protocols and certificates, etc. so please bear with me on the question :-). Thanks to any gurus out there that can help!
No, it's not possible.
As of right now, AFAIK there are no HTTP debugging proxies that support HTTP/3. For Fiddler specifically, they only shipped HTTP/2 support a few months ago (Jan 2022, 7 years after HTTP/2 was standardized) and only in Fiddler Everywhere. There's no mention of any timeline for shipping it in Fiddler Classic I can see, maybe never.
I can't speak for the Fiddler team's reasons, but I also maintain a debugging proxy and the general problem is that most languages don't yet have stable libraries available to easily handle HTTP/3, which makes it very difficult to support. There's some background on the causes of this here: https://daniel.haxx.se/blog/2021/10/25/the-quic-api-openssl-will-not-provide/. There are some experimental implementations available now, but in most cases nothing that's easy to integrate and reliable, unlike HTTP and HTTP/2 (normally provided as part of programming languages' core libraries, often with many battle-tested userspace implementations available too).
From the HTTP/2 approach, I would guess that HTTP/3 support in Fiddler is a couple of years away at least and will only be coming to Fiddler Everywhere, not to Fiddler Classic (but I don't know for sure - you'd have to ask them).
In the meantime, the best workaround available is to block HTTP/3 traffic entirely. Well-behaved clients should fallback to HTTP/1 or 2 automatically. Blocking all UDP packets on port 443 using a firewall will generally be sufficient (it can be used on other ports, but I've never seen it in practice).
I'm developing an application for iPhone which uses a HTTP request to get quote data from a webserver.
I am working with another developer who is managing the web service. We are using an MD5 encryption (simple xor) to pass the data between iPhone and webserver.
He posed a question to me this morning which is quite frankly way out of my pool of knowledge.
'How safe is the apple binary?'
He is worried about whether someone could obtain the .app bundle via iTunes, and then decode that bundle and access my source code directly, allowing them to obtain the secret key we are using to encode the data.
I personally, wouldn't even know where to begin, but i'm sure there are more knowledgeable/crafty fellows out there.
So, is it possible? if is it, what can I do to try and safe guard my source?
The binary is not even remotely safe. Whether through the iTunes download or on a jailbroken iPhone, there's nothing you can do other than obfuscation, which a determined adversary will always get past. Do not ever rely on the "secrecy" of something embedded in a client application, it is not secret. Ever. On any platform, in any language, with any technique.
If you need to limit who can access your system, you need per-user accounts. There is no other safe mechanism. Apple does provide ways to "authenticate" users via their iTunes accounts, you may want to look into that.
Also, "MD5 encryption" means nothing. MD5 is a hash function with cryptographic applications, but saying you're doing "MD5 encryption" and "simple XOR" is just meaningless. I can use XOR and MD5 to do any number of things, few if any would serve as a meaningful encryption scheme, and would have no advantages whatsoever over a real algorithm designed by experts, such as AES.
Use HTTPS (HTTP over SSL). There is no reason not to, the iPhone fully supports it. If you need to, you can get free SSL certificates for your server from at least http://www.startssl.com/ . There are lots of cheap SSL certificate providers out there these days, too. Google a bit.
I'd strongly recommend you and your co-developer start reading up on information security, both in theory and practice, because it appears you have very little grounding in the subject, and probably several significant misconceptions that will lead to easily-broken systems.
I was thinking about developing an app that enables the user to remotely check the progress of a longrunning task. The server application running the task is an existing commercial tool and comes with a proprietary client to connect to the server to manage it. However, the client is available only for windows computers and not for mobile devices, hence my desire to fill the gap.
The communication between client and server is neither encrypted nor password protected in any way.
What would be the best way to analyze or reverse engineer such a proprietary protocol?
Are there any legal implications (I know this is not the place to ask legal stuff, but if you happen to know how to reverse engineer stuff you maybe know whether it is legal or not, too)?
I'm a fan of http://www.wireshark.org/ for protocol analysis. Free, powerful, extensible, cross-platform.
As regards legal stuff: It depends on jurisdiction - and each country's courts seem to enjoy not coming up with consistent precedents. The general rule is reverse-engineering is okay for 'interoperability'. You'd really have to ask a lawyer for more info, though.
Personally if something is running on my machine and I want it to behave in a different way, I have no ethical issues forcing it to. That's just me, though.
I can fully imagine a virus writer ringing me up and making some kind of legal threats that I breached his EULA...
I need to develop a mobi site for a client, do I need a specific server setup for this, or are there any additional server configurations that I need in order to render a mobi site or does it work the same as a normal website?
A .mobi domain is not different (in terms of setup/configuration) than a .com
Even from a technological point of view, you can develop a mobile oriented application using the web technology (Java, PHP, Python, PHP...) and hardware infrastructure you prefer.
From the developer perspective, there's good instructions for .mobi compliance here, and ready.mobi is a great and free testing tool to evaluate mobile-readiness using industry best practices & standards.
ready.mobi is a great tool for testing compliance for this. Also, there's good instructions for .mobi compliance here.
I believe that you should check the availability of Javascript in the target platforms.
Your server should be able to serve pages with the application/vnd.wap.xhtml+xml MIME type, otherwise some WAP browsers wil not render the page correctly (Nokia series 60).
I'm looking for a way to give out preview or demo versions of our software to our customers as easy as possible.
The software we are currently developing is a pretty big project. It consists of a client environment, an application server, various databases, web services host etc.
The project is developed incrementally and we want to ship the bits in intervals of one to two months. The first deliveries will not be used in production. They have the puropse of a demo to encourage the customers to give feedback.
We don't want to put burden on the customers to install and configure the system. All in all we are looking for a way to ease the deployment, installation and configuration pain.
What I thought of was to use a virtualizing technique to preinstall and preconfigure a virtual machine with all components that are neccessary. Our customers just have to mount the virtual image and run the application.
I would like to hear from folks who use this technique. I suppose there are some difficulties as well. Especially, what about licensing issues with the installed OS?
Perhaps it is possible to have the virtual machine expire after a certain period of time.
Any experiences out there?
Since you're looking at an entire application stack, you'll need to virtualize the entire server to provide your customers with a realistic demo experience. Thinstall is great for single apps, but not an entire stack....
Microsoft have licensing schemes for this type of situation, since it's only been used for demonstration purposes and not production use a TechNet subscription might just cover you. Give your local Microsoft licensing centre a call to discuss, unlike the offshore support teams they're really helpful and friendly.
For running the 'stack' with the least overhead for your clients, I suggest using VMware. The customers can download the free VMware player, load up the machines (or multiple machines) and get a feel for the system... Microsoft Virtual PC or Virtual Server is going to be a bit more intrusive and not quite the "plug n play" solution that you're looking for.
If you're only looking to ship the application, consider either thinstall or providing Citrix / Terminal services access - customers can remotely login to your own (test) machines and run what they need.
Personally if it's doable, a standalone system would be best - tell your customers install vmware player, then run this app... which launches the various parts of your application stack (maybe off of a DVD) and you've got a fully self contained demo for the marketing guys to pimp out :)
You should take a look at thinstall(It has been bought by vmware and is called thinapp now), its an application virtualizer.
It seems that you're trying to accomplish several competing goals:
"Give" the customer something.
Simplify and ease the customer experience.
Ensure the various components coexist and interact happily.
Accommodate licensing restrictions, both yours and the OS vendor's.
Allow incremental and piecewise upgrades.
Can you achieve all of these by hosting the back end (database, web server, etc.) and providing your customers with a CD (or download) that contains the client? This will give them the "download/upgrade experience" that goes along with client software, without dealing with the complexity of administering the back end.
For a near plug-and-play experience, you might consider placing your demo on a live linux or Windows CD. Note: you need a licensed copy of Windows for the latter.
Perhaps your "serious" customers might be able to request their own demo copies of the back end as well; they'd be more amenable to the additional work on their part.
As far as OS licenses, if your vendor(s) of choice aren't helpful, you might consider free or open-source alternatives such as FreeDOS or linux.
Depending on if you can fit all the needed services into a single OS instance or not...
Vmware Ace or whatever they're calling it nowadays will let you deliver single virtual machines under strict control, with forced updates, expiration and whatnot. But it sounds easier to just set up a demo environment and allow remote access to it.
The issue here I guess is getting several virtual machines to communicate under unknown circumstances - if one is not enough?
An idea then is to ship a physical server preconfigured with virtualisation and whatever amount of virtual servers needed to demonstrate the system.
Using trial versions of the operating system might be good enough for the licensing dilemma - atleast Windows Server is testable for 60 days, extendable to 240 when registering.
Thinstall is great for single apps, but not an entire stack....
I didn't try it yet, but with the new version of thinstall you are able to let different thinstalled application communicate.
But I guess you're right a vm-ware image would be easier