The goal: a web service, secure, that will be called by exactly two clients, both outside the local network. The most obvious way to secure a web service is via https, obtaining a certificate from some CA. The problem is that this is a silly waste of money. The whole point of a CA is that it is a publicly trusted authority, so I don't have to verify my identity to every single person who wants to use my web page, the CA is doing that for them. However, when I'm dealing with a very small number of known clients, rather than the wide open public, I don't need anyone to vouch for me. We can do verification through our own channels.
Is there any way to accomplish this? Ideally, I'd be able to operate https with a certificate recognized by those calling my service, and if nobody else recognizes the certificate as valid, I don't care. I don't want them calling this service anyway. This should be a fairly common need in B2B data transfers (fixed-endpoint communications, rather than services intended for public consumption), and it is easy to do if you're transferring actual files (PGP-style encryption lets you simply verify and import one another's keys directly). But it isn't clear to me that this is possible with web sessions. It sure should be, if it is not. I have found some documentation of self-signed certificates, but they all seem to be intended for development purposes only, or internal use only, and expire quickly or require being on the same network.
Is there a good way to achieve this? Or am I going to have to encrypt the contents of the web service call instead? The latter is less desirable, because it would require the users of this service to add encryption code to their client applications (which assumes they are building these on a platform which easily can add support for common encryption routines, something that may or may not be true) rather than just relying on the standard, https framework.
I'm working on the Windows (IIS/ASP.NET) platform, if that makes any difference.
Creating your own CA and generating self-signed certificates is the way to go. There is no reason why they must be for development only, or expire quickly. You will be in control of this.
When I implemented this in a Java environment, the most useful resource I found was on Baban's Weblog. You can probably find a resource more relevant to your IIS environment.
To offer a secure service you don't need any certificate, only an https link. You are right that, in your case, a certificate does nothing for you. If your visitor insists on a certificate, then I second #sudocode's answer.
Our old authorization service used certificates, but in rebuilding it we got rid of the certificates and went to an Amazon ec2 style security for the services.
Related
I want to pen test rest apis, the use case I have is a client(desktop app with username and password) connecting to a server. So I am confused from where to start and how to configure burp. Usually I use burp to pen test websites, which is quite easier to configure, you only set the proxy and intercept in the browser, but now the use case is different.
Furthermore, I did some search on google I noticed postman is mentioned many times, I know it's a tool for building apis, but is it also used in the pentesting with the burp?
It may be useful to first confirm that the application is communicating via HTTP/HTTPS to ensure Burp is the right tool to use.
Postman is only useful for penetration testing if you already have Postman docs. It doesn't sound like that's the case here so I wouldn't worry about that.
Assuming the desktop app does use HTTP, there are two things you will need to do:
Change system-level proxy settings to point to Burp (127.0.0.1:8080)
Install and trust the Burp CA Certificate (available locally from http://burp:8080).
In some cases you might need to enable 'invisible proxying' in Burp.
Depending on the type of client, this may not always work at first, but if the client supports a proxy, you should see the traffic in your Burp window. Please do pay attention to your Dashboard in Burp, if you see TLS warnings, it may be an indicator the client uses certificate pinning, and some reverse engineering may be needed on the client.
As you know, burp, intercept a http/s protocol network and it isn't a tool for intercept network traffic. so To achieve your goal, you can use the wiresharkor something else, for finding a software rest api endpoint.
After that, you can start your penetration testing using the burp as you did before.
so how you can find rest api endpoint in wireshark?
you can filter network results, using this pattern:
tcp.port==443
I've a server which authenticates clients applications and allows them to execute or not. I want to have a secure channel between server and clients. I've written my server with both ssl and ssh protocols but I don't know which one must be used in these scenario and which one is more logical.
both client and server has been written in Qt,c++.
ssl is mostly used in https and web based application and ssh is used for remote administration, so I think that ssh is more appropriate for my server. also I think it's not a good design if I release my application with certificates(exe file along with a certificate.)
Both ssl and ssh use the same, fundamental, cryptographic technologies. Looks like you understand the practical differences between the two, so use whichever one is convenient for your application. As long as you follow proper security practices (keeping your certificates and/or private keys under a watchful eye, etc etc etc), either one will give you the same, basic, level of security.
Well. I created reference, tested on local machine all is well. Deployed solution to production server and here we go:
An error occurred while trying to make a request to URI
This could be due to attempting to access a service in a cross-domain
way without a proper cross-domain policy in place, or a po
From what I gathered - it's security measure to prevent something (not sure what). Well. I can't make provider to put clientaccesspolicy.xml and crossdomain.xml.
What is my options? Looks like either running Silverlight app in elevated mode or.. ?
I don't want to require elevated trust.
The only way I know is to call my server and make call to webservice from my server returning data back to client. Seems like too much overhead. Is there any better way? Really frustrating.
I'm afraid your options are limited here. In compliance with Same Origin Policy the cross domain policy file is a must. Here you can find an example why. Personally I would go down the route of proxying the remote web service via your hosting server if you can't influence the provider.
What advantages are there between implementing SOAP messages over SSL by modifying the web.xml/ejb-jar.xml VS modifying the WSDL with a WS-Policy?
Our project can acheive its goal of having our clients (ourselves) access the Web Service over a secured connection by adding a transport-guarantee but we're not sure if that is a complete/correct solution.
With SSL, you get a point-to-point encryption between client and service. If the service is not the ultimate receipient of the message, but a proxy that routes this message to another service, you have no encryption between the two services, or you have to configure that also.
WS-Security configured via WS-Policy has the potential to give you end-to-end encryption between the client and the ultimate receipient of the message, because you can encrypt the message body. You do not need to configure SSL for every pair of communicating entities. Every proxy can just route the message on, as defined in the header.
That said, if you do not need end-to-end guarantees, but point-to-point is enough (which is your scenario, as far as I understand), I would say that using SSL is a fair choice.
Another thing to consider is that the WS-Security implementations of client and service need to be able to interoperate. SSL generally is quite mature, but my personal experience is that WS-Security implementations are not. So, if you have different WS-* Stacks for client and server, it might be some hacking and trial-and-error to find a policy configuration that works for both.
I'm setting up a web service which will only be used by a limited number (< 100) of known agents (business partners etc.).
Because I am not public facing, do I face any real downside to using self-issued certs as opposed to the much more costly route of using a known CA?
Edit: I should clarify that the primary purpose we hope to get out of the certificates is to fulfil the 2nd factor in two-factor authentication (password for what-you-know, X.509 cert for what-you-have)
There's no real downside, but it's easier to use a private CA in those circumstances. That private CA has a self-signed certificate, and authorizes everything else in your closed world. Write down a policy (you know, on a piece of paper) for who gets their certificate signed and how you go about doing the signing, and you'll be operating like the “real” CAs do.
But if there are external business partners involved, it's probably easier to just use a normal CA. You can get your service certificates signed for very little so cheap-skating on them is just not really worth it. It only becomes a hassle when you start to want to do things like delegated authority and things like that; at that point, you want to start reading about OAuth and FOAF+SSL. And maybe other things too; it's a deep rabbit-hole.
With a self-signed cert, the users will be warned that the certificate is not trusted by the browser until they manually add the signing certificate into their certificate cache, or will have to click to accept the fact that the certificate may be untrusted.
With a known CA such as Verisign, the signing certificate will typically already be preinstalled on their PC, so the user will receive no prompt
Also a security consideration (from Wikipedia - haven't encountered this myself): "Self-signed certificates cannot (by nature) be revoked, which may allow an attacker who has already gained access to monitor and inject data into a connection to spoof an identity if a private key has been compromised. CAs on the other hand have the ability to revoke a compromised certificate, which prevents its further use."
I would think most security-conscious people would hesitate to import some guy's root certificate. Heck, i have certificates i've generated MYSELF that i don't want to import. And a lot of software will refuse to deal with a server whose cert isn't issued by a CA it (or the OS) trusts.
Seriously, check out http://www.startssl.com. They offer free certificates, which appear to be pretty well supported by most common browsers and OSes. It's a lot easier than even trying to tell people how to install your root cert.