We want to setup HTTPS for our TFS (on premise)
According to the documentation of Microsoft the disadvantages of requiring HTTPS for TFS are (besides some other disadvantages):
You might complicate ongoing administration tasks. For example, you might have to reconfigure your deployment to stop supporting HTTPS with SSL before you can apply service packs or other updates.
If you require HTTPS with SSL, your deployment's performance will be slower.
I can imagine that it will become a bit slower because of the encryption. I assume most environments are set up with HTTPS.
Does someone really experience these kind of issues?
The advantages and disadvantages have been listed in documentation Setting up HTTPS with Secure Sockets Layer (SSL) for Team Foundation Server:
Advantages of Supporting HTTPS with SSL in Addition to HTTP
If you configure your deployment of TFS to support both protocols,
users whose computers have been configured for HTTPS with SSL will
connect by using that protocol, which makes your deployment more
secure. In addition, users whose computers are configured for HTTP
only can still connect to your deployment. Although you should not
deploy this configuration over public networks, you can gain the
following advantages by continuing to support HTTP connections in a
controlled network environment:
You can increase the security of your deployment over time by configuring client computers for HTTPS with SSL as your schedule
permits. If you take a phased approach, you do not need to upgrade
all computers at the same time, and users whose computers have not
yet been upgraded can still connect to the deployment.
You can more easily configure and maintain Team Foundation Server.
Calls from one Web service to another are faster over HTTP than over HTTPS with SSL. Therefore, you can continue to support HTTP
connections from client computers for which the performance
requirements outweigh the security risks.
Advantages of Requiring HTTPS with SSL for All Connections
If you require HTTPS with SSL for all connections, you gain the
following advantages:
All web connections between the application tier, the data tier, and the client tier for Team Foundation are more secure because
they require certificates.
You can control access more easily by configuring certificates to expire when a project phase is expected to end.
Disadvantages of Supporting or Requiring HTTPS with SSL
Before you configure TFS to support or require HTTPS with SSL, you
should consider the following disadvantages:
You might complicate ongoing administration tasks. For example, you might have to reconfigure your deployment to stop supporting HTTPS
with SSL before you can apply service packs or other updates.
You must not only configure but also manage a certification authority (CA) and certificate trusts. You can use Certificate
Services in Windows Server 2003 and Windows Server 2008, but you
might not want to invest the time and resources that deploying a
secure public key infrastructure (PKI) requires.
You must spend significant time setting up and testing either of these configurations, and troubleshooting your deployment will become
more difficult.
If you continue to support both protocols, external connections might not be encrypted if the application tier for Team Foundation
is not appropriately secured.
If you require HTTPS with SSL, your deployment's performance will be slower.
Using HTTPS makes your deployment more secure, and as #Edward mentioned, using HTTPS is well-supported and recommended. Indeed HTTPS is slightly slower than HTTP with no encryption, but it's hard to imagine this actually being a problem. If you meet any issue using HTTPS, you could open a new case with detailed information so that we can provide better support.
Related
I'm new to mobile development and was wondering if it is an anti-pattern to have a remote, configuration server in order to 'configure' a mobile client. The idea is to avoid configuration details [except the URL to the configuration server] with the mobile distribution and rather connect to the configuration server to grab other details such as third party keys, service endpoints, etc. Any thoughts. Thanks in advance!!
So long as you are able to secure connections to the the configuration server, using a username/password and SSL encryption it's not an anti-pattern. It would save you from publishing new applications versions just to update some configuration.
What does however sound like a bad idea to me is keeping third-party API keys inside a mobile application.
Can you guarantee that each an every user using you application will not use the keys placed inside the mobile application to use the third party service to their own ends? I don't think anyone can make that guarantee.
I am working on an chat program with socket programming (Indy in Delphi).
What security solutions can I use to satisfy its security? From user authentication (I used a server to authenticate users) and type of packets security that can be used?
I don't have any idea what can make my app vulnerable.
Indy supports OpenSSL so yo only need to add and configure a OpenSSL handler, and make sure that the firewall allows connections over the secure port.
A popular source of information is the Open Web Application Security Project (OWASP).
Their pages include lots of technical article, for example
https://www.owasp.org/index.php/Category:Vulnerability
about vulnerabilities
Long ago I started some "web applications" using Delphi 2007 and WebBroker (TWebModule). At the time I assumed you needed a webserver such as Apache or Microsoft IIS in order to create any sort of website. Additionally I don't use most of the Apache features (except for Virtual Server so I can have multiple domains on a single ip address and SSL). So to me Apache is just an extra layer and makes makes debugging difficult.
Now enter Indy (TIdHTTPServer). If I understand correctly, Indy IS a webserver. So by using Indy I am no longer bound to use Apache or some other webserver. Is this correct?
Will I have any issues supporting the Virtual Servers in an Indy environment? And what about SSL. I have searched the literature and from what I can see it fully supports SSL certificates.
I am now in the process of porting some of my application from WebBroker to Indy. This mostly entails replacing within my code references of Request: TWebRequest with ARequestInfo: TIdHTTPRequestInfo and references to Response: TWebResponse with AResponseInfo: TIdHTTPResponseInfo.
Is there anyway to use the TWebModule architecture within Indy so that I don't need to do all of this rewriting?
Lastly is there anything else I need to be concerned with? My goal is to take Apache out of the loop.
Yes, you can use Indy's TidHTTPServer as a webserver, but it's much lower-level than IIS or Apache. There is no concept of virtual servers - this you would have to implement yourself.
Indy does support SSL as well via the OpenSSL dll's.
I imagine the biggest concerns you will have will be security related...there are millions and millions of sites running Apache or IIS and there are a ton of people devoted to finding flaws in those platforms, with a bunch of people fixing some of those flaws as they come up. Not so with Indy... there's one or two guys that respond on newsgroups to bugs that you discover. (One guy in particular, who will probably respond to your question here as well.)
Now, I use Indy HTTP server (along with SecureBlackBox SSL support) and I find it to be great for my purposes.
Indy HTTP server calls the WinSock API, and is able to implement:
A full HTTP/1.1 server;
A full HTTPS server (using either OpenSSL libraries or other third parties, like SecureBlackBox).
AFAIK you can use Indy to publish web modules.
See http://www.2p.cz/files/2p.cz/downloads/howto/indy_soap_web_services_in_delphi.pdf
You can also use other servers, for instance directly the kernel-mode http.sys server, which is used by ISS and .Net WCF for instance, and known to be very stable and efficient (it bypasses the WinSock APIs). Of course, it will serve HTTPS conent, if needed. It is available in standard since Windows XP SP2, and therefore in Vista and Seven. Using this component will let Microsoft will do all the debugging work for you, and it will be updated with the host OS. I use it for instance in our Client-Server ORM, or directly to replace a deprecated DCOM connection, with very good speed and stability on customer side.
Regarding virtual servers - the HTTP 1.1 spec requires clients to send a Host request header so virtual servers know which domain is being used specifically to handle the case when multiple domains have the same IP. TIdHTTPRequestInfo has a Host property for that value. In fact, TIdHTTPServer internally validates to makes sure that an HTTP 1.1 request has the Host header before firing any of its OnCommand... events.
With the upcoming SSL migration at Facebook on 1 October, all apps will have to support connections over HTTPS and for that you'll need an SSL certificate.
Is there a run-down anywhere of how a person should patch an app?
Will you have to use Apache and Passenger, xginx or other server?
Are there any free trusted certificates?
Is there a run-down anywhere of how a person should patch an app?
Not really. Why? Because it all depends on what version of rails you are running.
For Rails 2.x, I've read/heard of techniques including:
ModRewrite - use the webserver's ability to detect and rewrite HTTP to HTTPS. This technique is more general and could apply to a whole host of technologies, not just rails (python, java or even .net).
Use ssl_requirement gem - this allows you to declaratively add instructions in your controllers to redirect to https if the protocol is http (https://github.com/retr0h/ssl_requirement). Although simple, your ruby app will have to handle the request, and I'm not sure how quick ssl_requirement is.
Use rack middleware (rack-ssl, rack-ssl-enforcer gem) - this patches the request handling of rails, so that the redirect is handled well before it hits any controller. This is configureable too (you can match based on path etc) and is probably better than option 2.
For Rails 3.1, it's backed into the framework. You just need to do this:
# config/application.rb
module MyApp
class Application < Rails::Application
config.force_ssl = true
end
end
Will you have to use Apache and Passenger?
Not necessarily. There are other options like NGinx and Passenger. But in general, yes you will probably need a proper web server sitting in front, handling the SSL portion of the request.
Typically, a web server is required to sit in front of your app. It needs to be configured to handle SSL traffic, and direct the requests to your app (http and https). Here you can use Apache or NGinx.
Passenger sits as a "plugin" in Apache/NGinx to handle requests through to your application. At this point, SSL isn't usually a concern (ie. the request is now unencrypted.). What your app has to then do, is handle the request. Here's where you detect if the protocol is http or https and instruct the browser to redirect if necessary.
Are there any free trusted certificates?
No. Trusted certs are usually signed by a Certificate Authority. These guys typically have to check that your domain and the company or individual that holds the domain are genuine and real. To do that, you pay money. There are plenty of providers out there that can issue you an SSL cert for around $100 USD. Some more, some less.
Certs are typically locked to a domain. And you pay more for wildcard domain matches (e.g. *.myapp.com). If you're after a cert for development, you can generate a self signed certificate.
I've written an article showing you how to get HTTPS going on your local dev instance. Many of the steps are also common for production. The article shows you how to set it up for POW and NGinx, but setting up for Apache and Passenger isn't too dissimilar. The Apache config is different. But Passenger install and setup should be just the same as a http environment. Just need to make sure the secure virtual host in your Apache config points to your application.
I'm currently tasked with setting up a TFS server for a client. The TFS will mainly be accessed by local (on-site) users through the internal network... Easy!
But what about the few remote users we have? Should they connect via VPN or is it better to make the TFS server public and have the users connect over SSL and provide username and password to the TFS?
Do you have any suggestions on how these solutions will perform compared to each other?
VPN is the way to go if you want the optimal TFS experience with TFS 2005 or TFS 2008. While TFS mainly uses web service based protocols that can all go over SSL, there are a few small things that will not work unless you have proper network access. For example:
Viewing the Build Log (unless worked around)
Access Team Build drops
Publishing Test Results
As well as a few other little niggles. Going the VPN route will also mean that your TFS installation will vary less from a standard base TFS installation which gives you some peace of mind that you won't run into any problems when it comes to upgrading to a new version, applying service packs etc. (or at least any problems you run into will have been run into by many before :-) ). Going the SSL route you are treading a less worn path - though obviously plenty of people do run it that way including CodePlex and all the commercial companies that provide a hosted TFS installation.
The downside of VPN is that usually you are granting users to an entire section of your network (unless you are running TFS in it's own mini private network or something). If you go down the SSL route then be sure to properly test the new team projects as this is easy to break and you might not realise until you try and create one either inside or outside the network.
For additional information, see Chapter 17 of the TFS Guide.
I'd start with a few questions: does the client have a VPN? And are the remote consumers on this VPN already? How secure does this need to be?
(In our case, we have lots of outside vendors we don't want on our VPN, so our source control is publicly accessible with SSL)
When I did it, I used a VPN. Was easier to setup, and made sure that no-one could even see the machine with out being authenticated via the VPN - this was obviously way better from a security standpoint, which trumped any performance benefit we would have got from using SSL, if there even was one...
My previous experience with TFS was in an environment where we had a team of developers staffed out at client sites all over the city. In many situations we still accessed our TFS instance instead of something at the client site. We used SSL with public access to TFS. It worked very well for us.