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).
Related
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.
Does Restful Webservices have any service registries like the UDDI? Or can UDDI hold Restful Webservices as well?
UDDI can be used for REST services. WSDLs can be used to described HTTP web services, but frankly I feel that it's not a real match for a REST resource architecture.
At a most basic level, UDDI is simply mapping of attributes to service endpoints. So, if you're simply looking for a system that can do that, then UDDI will fit the bill.
UDDI is not popular in the wild, wide open internet, but it is used "behind the scenes" as an orchestration component.
As Darrel mentioned, DNS is another valid discovery mechanism.
My personal complaint with DNS is simply that even though DNS has all of the advantages that's mentioned in the article he cites, the downside is that DNS is such a critical part of the network fabric, it tends to not be available to developers. Typically, the network operations folks (who tend to be more notorious than even DBAs) hold infrastructure like DNS quite close. Finally, while DNS is quite capable of these tasks, in many cases the standard default configuration and deployment of DNS may need to be changed. For example, We've started serving certificates from DNS, for example, and we had to enable TCP for DNS. Again, this meant more involvement of network ops.
On top of that, while there is a lot of expertise and knowledge of DNS out in the world, knowledge and expertise of HTTP and "doing stuff" on a web server is far greater. That consequences of that simply means that when developers think about and look to some kind of solution to this problem, the first place they're going to look is likely an HTTP based solution.
So, in that sense UDDI is possibly a better solution, just in terms of being able to get it rolled out quickly with little hassle.
Of course, UDDI is a SOAP based service. That's not that big a deal, really. Not a great fit for a RESTful system, but it's not awful. Functional, if a little "impure".
As for a standard HTTP based service registry, there's nothing that I know of. It's reasonably simply to adhoc one simply with HTML, for example. The fact that UDDI hasn't taken off in the World at large isn't so much a limitation or slight against UDDI. Rather it's simply that the vision of discovering arbitrary services hasn't really come to fruition, the need simply isn't quite there. There's a lot more involved out of band with service discovery beyond location and semantics, like business relationships and such.
Internally, within the enterprise, those logistics are solved, so service discovery has value. Out in the wild, not so much.
It's not dead ;)
signed a jUDDI developer
juddi.apache.org
Edit: There's also WS-Discovery which is supported by both CXF and WCF. Worth checking out.
FWIW, UDDIv3 does specify a REST interface, however I don't think anyone other than jUDDI has implemented it. It will be included with v3.2 and up using CXF, Jettison and WADL. Source: http://svn.apache.org/repos/asf/juddi/trunk/juddi-rest-cxf/src/main/java/org/apache/juddi/api/impl/rest/UDDIInquiryJAXRS.java
UDDI was designed for SOAP services, however, it is not even used for those any more. UDDI was pretty much dead as of 2006.
This article shows how to use DNS to do discovery.
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've been looking at these too, both seem to provide fully functional XMPP servers in Java. I know Tigase is designed in a very modular way, not looked at Openfire in as much detail yet.
My intended use would be to create a custom IM-based app, using XMPP for convenience rather than to open my server up to talk to other XMPP servers.
I'm trying to evaluate my needs based on the following, roughly in order of importance:
Documentation coverage & community
How easy to plug in own functionality
Licensing/cost - I don't plan to release my code
Maturity and stability
Do not use Openfire if you expect to scale beyond a couple of thousand concurrent connections.
Tigase is amazing at handling hundreds of thousands concurrent connections and is wonderfully architected for largely distributed platforms where XMPP is simply the external interface. It comes with a price of rather poor documentation. You often need to go and read the source code to understand what's going on.
Openfire is perfect for small setups and its API is simple and very well documented. Unfortunately, it's not architected to scale even nearly close to what tigase is capable of.
Tigase is GPL(even version 3) licensed opposed to OpenFire being under Apache license ... for closed source application is OpenFire the go.
It is embaddable and proven to be reliable - 1000s of concurrent users. It even has gateways to communicate with legacy networks - like ICQ.
Only drawback I can se here is that it can handle only one domain per instance(port), however from your description that should not be a problem.
I totally agree with #Yuriy in that Tigase is great for high scalability whereas Openfire is more suitable for small, novice IT running chat for a SMB. I have gone into more detail on this in my blog on Tigase vs Openfire.
And Openfire 3.7.0.beta is out since some days now.
Lots of bug fixes, now also support Solaris as host system.
Concerning openfire ... it seems to be more or less abandoned and certainly not because of lack bugs to fix ;)
Is there a way I can make a request to a different server than the one that's being used for development using a RequestBuilder?
I keep getting
com.google.gwt.http.client.RequestPermissionException: The URL
http://127.0.0.1:4321/getSellers is invalid or violates the same-origin
security restriction
while I am sending request from 127.0.0.1:8888
GWT currently doesnt support cross domain ajax calls - but it can be worked around if you are willing to do a bit of jsni. And I heard a rumour some time ago that there is a gwt patch with the solution, but its not perfect. see this http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/94c18c4ec158070c/
to work around using jsni, you can use whats called the windows.name transport - see this blog http://www.sitepen.com/blog/2008/07/22/windowname-transport/ . i havent been able to locate a library for gwt to automate this, but i dont think its too hard to do yourself in jsni (and dont me misled by the blog being about dojo, its a general technique).
There is a detailed explanation on the topic of the Same Origin Policy and its consequences for developing with GWT here:
http://code.google.com/p/google-web-toolkit-doc-1-5/wiki/FAQ_SOP
The simple answer is: No, that's something that is disallowed for security reasons.
However, it should be possible to work around this limitation with all kinds of techniques (proxy servers, Yahoo Pipes, etc). As I'm no AJAX expert, I will leave the explanation of those to others.