HTTP Secure, Part II. Is Diffie-Hellman always used in the HTTPS key exchange?

I got a question right after I had spent a week in training classes for the COMPTIA Security+ exam: to describe how HTTP Secure (HTTPS) modifies the HTTP traffic between a client browser and the server.

At the end of my explanation, this person also asked me what was the role of Diffie-Hellman algorithm in the whole process.
I was almost sure that Diffie-Hellman isn’t used all the time in HTTPS  but I didn’t know how to explain, on the spot, when is Diffie-Hellman actually used. The person asking me the question was part of a review board and was adamant that Diffie-Hellman was always used.
I’ll abbreviate Diffie-Hellman as D-H for the remaining of this post.

How is the HTTP traffic between a server and a client modified when the channel is encrypted? What is SSL?

What is the role of the D-H key exchange algorithm?

Is D-H always used in HTTPS?

Those are the questions I’ll try to answer on this post.

How is the HTTP traffic between a server and a client modified when the channel is encrypted?

Similar to an HTTP request, the client begins the process by requesting an HTTPS session. This could be by entering an HTTPS address in the URL or by clicking on an HTTPS hyperlink. Now, when the link must be secured the server responds by sending the server’s certificate. The certificate includes the server’s public key. The matching private key is on the server and only accessible by the server. The client then creates a symmetric key and encrypts it with the server’s public key. The creation of the symmetric session key is what differs in the different versions of SSL and could use D-H in some cases for the generation of the exact same key by the client and the server, so the key is never actually exchanged.  This symmetric key (also called ephemeral key or session key) will be used to encrypt data in the HTTPS session.  When D-H is not used, the client sends the encrypted session key it generated to the web server. This key is encrypted using the server’s public key. Only the server’s private key can decrypt the cypher and obtain the client’s session key. If attackers intercept the encrypted key, they won’t be able to decrypt it since they don’t have access to the server’s private key.  The server receives the encrypted session key and decrypts it with the server’s private key, this is not true when D-H is used though, as the server generates an identical session key as the one that was generated by the client. At this point, both the client and the server know the symmetric/session key. All of the session data  exchanged over the link is encrypted with this symmetric/session key using symmetric encryption.

In the case the server is configured to accept client certificates to authenticate the client, the exchange differs a little from the one described above. Digital certificates provide a way for the clients to trust the server with validations that can be done of the certificate presented by the server, but this subject (client certificates involved on the HTTPS exchange and server authentication using digital certificates) is beyond the scope of this post.

What is SSL?

SSL Secure Sockets Layer (SSL) is an encryption protocol used to encrypt Internet traffic. For example, HTTPS uses SSL in secure web browser sessions. It can also encrypt other transmissions. For example, File Transport Protocol Secure (FTPS) uses SSL to encrypt transmissions. SSL provides certificate-based authentication and encrypts data with a combination of both symmetric and asymmetric encryption during a session. It uses asymmetric encryption to privately share a session key, and symmetric encryption to encrypt data displayed on the web page and transmitted during the session. Netscape created SSL for its web browser and updated it to version SSL 3.0.  The IETF created TLS to standardize improvements with SSL. TLS Transport Layer Security (TLS) is a replacement for SSL and is widely used in many different applications. The IETF has updated and published several TLS documents specifying the standard. TLS 1.0 was based on SSL 3.0 and is referred to as SSL 3.1. Similarly, each update to TLS indicated it was an update to SSL. For example, TLS 1.1 is called SSL 3.2 and TLS 1.2 is called SSL 3.3.

SSL keeps the communication path open until one of the parties requests to end the session. The session is usually ended when the client sends the server a FIN packet, which is an indication to close out the channel. SSL requires an SSL-enabled server and browser. SSL provides security for the connection but does not offer security for the data once received. In the protocol stack, SSL lies beneath the application layer and above the network layer. This ensures SSL is not limited to specific application protocols and can still use the communication transport standards of the Internet. Different books and technical resources place SSL at different layers of the OSI model, which may seem confusing at first. But the OSI model is a conceptual construct that attempts to describe the reality of networking. The SSL protocol works at the transport layer. Although SSL is almost always used with HTTP, it can also be used with other types of protocols. So if you see a common protocol that is followed by an s, that protocol is using SSL to encrypt its data. SSL is currently at version 3.0. Since SSL was developed by Netscape, it is not an open-community protocol. This means the technology community cannot easily extend SSL to interoperate and expand in its functionality. If a protocol is proprietary in nature, as SSL is, the technology community cannot directly change its specifications and functionality. If the protocol is an open-community protocol, then its specifications can be modified by individuals within the community to expand what it can do and what technologies it can work with. So the open-community version of SSL is Transport Layer Security (TLS). The differences between SSL 3.0 and TLS is slight, but TLS is more extensible and is backward compatible with SSL.

 

The SSL/TLS Handshake Protocol
The most complex part of SSL is the Handshake Protocol. This protocol allows the server and client to authenticate each other and to negotiate an encryption and Message Authentication Code (MAC) algorithm and cryptographic keys to be used to protect data sent in an SSL record. The Handshake Protocol is used before any application data is transmitted. The Handshake Protocol consists of a series of messages exchanged by the client and the server.

The Figure below shows the initial exchange needed to establish a logical connection between the client and the server. The exchange can be viewed as having four phases.

Handshake Protocol in Action 

After sending the client_hello message, the client waits for the server_hello message, which contains the same parameters as the client_hello message. For the server_hello message, the following conventions apply. The Version field contains the lower of the version suggested by the client and the highest version supported by the server. The Random field is generated by the server and is independent of the client’s Random field. If the SessionID field of the client was nonzero, the same value is used by the server; otherwise the server’s SessionID field contains the value for a new session. The CipherSuite field contains the single CipherSuite selected by the server from those proposed by the client. The Compression field contains the compression method selected by the server from those proposed by the client.

What is the role of the D-H key exchange algorithm?

D-H is a key exchange algorithm used to privately share a symmetric key between two parties, it wasn’t deviced in the context of digital certificates and pre-dates them. The Diffie-Hellman scheme was first published in 1976 by Whitfield Diffie and Martin Hellman. The idea of D-H is that it’s easy to compute powers modulo a prime but hard to reverse the process: If someone asks which power of 2 modulo 11 is 7 , you’d have to experiment a bit to answer, even though 11 is a small prime. If you use a huge prime istead, then this becomes a very difficult problem

The D-H algorithm enables two systems to exchange a symmetric key securely without requiring a previous relationship or prior arrangements. The algorithm allows for key distribution, but does not provide encryption or digital signature functionality. The algorithm is based on the difficulty of calculating discrete logarithms in a finite field. The original Diffie-Hellman algorithm is vulnerable to a man-in-the-middle attack, because no authentication occurs before public keys are exchanged.

Is D-H always used in HTTPS?

The answer is NO. In practice, Diffie–Hellman is not used with RSA being the dominant public key algorithm.

The first element of the CipherSuite parameter (see the Handshake Protocol in Action figure above) is the key exchange method. The following key exchange methods are supported on HTTP Secure:

RSA: The secret key is encrypted with the receiver’s RSA public key. A public-key certificate for the receiver’s key must be made available.
Fixed Diffie-Hellman: This a Diffie-Hellman key exchange in which the server’s certificate contains the Diffie-Hellman public parameters signed by the certificate authority (CA). That is, the public-key certificate contains the Diffie-Hellman public-key parameters. The client provides its Diffie-Hellman public key parameters either in a certificate, if client authentication is required, or in a key exchange message. This method results in a fixed secret key between two peers, based on the Diffie-Hellman calculation using the fixed public keys.
Ephemeral Diffie-Hellman: This technique is used to create ephemeral (temporary, one-time) secret keys. In this case, the Diffie-Hellman public keys are exchanged, and signed using the sender’s private RSA or DSS key. The receiver can use the corresponding public key to verify the signature. Certificates are used to authenticate the public keys. This option appears to be the most secure of the three Diffie-Hellman options because it results in a temporary, authenticated key.
Anonymous Diffie-Hellman: The base Diffie-Hellman algorithm is used, with no authentication. That is, each side sends its public Diffie-Hellman parameters to the other, with no authentication. This approach is vulnerable to man-in-the-middle attacks, in which the attacker conducts anonymous Diffie-Hellman exchanges with both parties.

 

References:

Harris, Shon. CISSP All-in-One Exam Guide, Fifth Edition (Kindle Locations 16125-16152). McGraw-Hill.

SSL: Foundation for Web Security – The Internet Protocol Journal – Volume 1, No. 1

Gibson, Darril. CompTIA Security+: Get Certified Get Ahead: SY0-301 Study Guide 

The Secure Sockets Layer Protocol

HTTP over TLS

Diffie Hellman Key Agreement Method.

How time is spent on web development

Dear reader,

Ok, the image above is pretty… and pretty hilarious as well. I must say that some of these time lines are true though. No, I don’t hate 100% IE, I still think it was the first browser that introduced the XmlHttpRequest as part of JScript in a very early version (maybe IE4) during the Netscape vs IE war. Somehow IE prevailed and also enabled the Ajaxian websites we see today. If you remember how bad it was to make a site work in Netscape, you’ll understand why I’m glad it died in 2002 :-p

That being said, the time lines are  somehow accurate. Unfortunately web development with HTML rendering on a browser has many places where things can go wrong, and prototyping is just a smaller time, even if the prototype looks real and very cool and I’m referring to either a pure HTML prototype or a set of images created with a prototyping tool)

If you inherit an existing CSS and a certain master page or left navigation, things can get complicated if you don’t keep your styles pruned out, and if you use pure CSS, introducing new elements in an existing page can be a nightmare, the existing elements can shift easily.

If you add to that, that FF and IE have a different box and a different way to represent positioning (margin and padding), things can get messy for cross browser compatibility.

JavaScript also requires extra effort and strings without escaping quotes, for example single quotes can break anything injected on the JavaScript when the DOM is created on the document create event in the browser.

In the past few years, the outcome of JavaScript libraries such as JQuery, Dojo and GWT have made the life of developers easier.

I wonder if in a few years the world will move away from HTML/JavaScript and go to web sites developed with alternate means, ie Silverlight/Flex…how would the pie chart above look like?

Cheers!

PS. The subject of this blog post might not necessarily align with my employer or coworker’s opinion and it is given only as a comment. Oh, and I never swear…

Things you should know when debugging JQuery and Javascript inside your partial Views in ASP.NET MVC

Well, I’m heavily using JQuery now on a web application and I must say I’m very fond of this library.

It’s very easy to use, encapsulates quite a few cross browser compatibility issues so the developer doesn’t have the pain to check what browser the page will be displayed on. The ajax calls ($.get, $.ajax and $.post) work like a charm and the pages can have painless and cool animations and effects.

But, no matter how robust and sturdy a library is, we always need to debug. I must say Visual Studio 2008 is heaven to debug JavaScript code. I just have to put the debugger; keyword in front of the line to create a break point. The IDE shows the iexplorer.exe process and thread ID (you can also chose to debug on FF or your favorite browser). You can review your locals, add to the Watch Windows or just take a sneak peek with Quick Watch.

All the power of strongly type language debugging is now available for the type agnostic JavaScript and believe me, this is priceless when you debug JSON.

Happy JQuery debugging!

Oops, this post was about debugging JavaScript on the partial views in MVC…

Now I remember what I was suppose to comment on:

If you use your Model properties inside your JavaScript code, you won’t be able to put this code on a separate .js file and include it on your main view header or even include it on your partial view. It won’t work.

Unfortunately the javascript code should be embedded along with your MVC markup on your partial view. You see, the rendering of these HTML helpers happen first on the server side before the page is served, while the js include happens after. Maybe MVC will be smart enough to detect these js includes in the future and render any helper content inside the js includes, as of MVC 2.0 RTM, this is not possible.

Done!

HTTP 1.1 caching directives for dummies and caching problems for old versions of Internet Explorer.

The reason why I published this link is because a coworker had a problem with viewing a PDF on IE6 when the cache was set to no-store over https.

The problem does not happen with Internet Explorer 7 or above or with FireFox, but the old IEs fail to retrieve the files when the cache directive is no-store or no-cache.

More of this on:

Internet Explorer file downloads over SSL do not work with the cache control headers

Unable to Open or Run Files if “Cache-Control: No Store” Header Set

and

Prevent caching when you download active documents over SSL

And another good reading on Caches on the web:

Caching Tutorial for Web Authors and Webmasters

Composing web applications with the ASP.NET frameworks in the market… MVC 2 Areas vs MVC with MEF

On my previous post I ranted about the need my team has for a plug in implementation for a web portal. I’m sure this requirement is on almost every web team that develops a web portal.

We were paying close attention to the ASP.NET MVC framework in conjunction with MEF:

MEF and ASP.NET MVC sample

and see great potential here. the only drawback is that plug ins will run as part of the same application domain, afaik. This might not be a drawback if your plug ins do not need to be hosted on a different service and domain.

We took a close look at the Areas in ASP.NET MVC 2 Preview 1 recently released, but the concept of Areas is mostly for organizing big web projects, not for developing modules as plug ins.

See the copy and paste from this blog post by Haacked:

… right now, Areas isn’t intended to address the “pluginnable” architecture. We started going down that route but it raises a lot of challenging questions such as where does the database go and how do you handle communication via areas and how do you administrate plugins?

I’m not sure that the core framework at this time is the place to put these concerns. I see this as something that might be better left to a higher level framework on top of ours, much in the way that DotNetNuke or Drupal are hosts for plugins.

However, I’m not closing the door on this, but I think you’ll see we’ll take a very iterative incremental approach. Right now, Areas is focused on helping teams manage the complexity of an application. It’s a small step. We’ll be looking at application composition as we move forward.

@Peter, For the security boundary question, at the end, it’s still just one application. Everything is merged into the same app running in the same AppDomain. So they share the same security boundary in that regard. Of course, you can use AuthorizeAttribute and other means to create security boundaries around areas should you choose.

I’m not sure my team would like to go for DotNetNuke unless it is rewritten on MVC, this is only my personal opinion and I would have to POC further before reaching a conclusion.

MEF so far looks like a good candidate…

Can cross browser communication solve my need for a true composite web application or SSO is the best way to go?

I must confess that the lack of posts on my blog are mainly due to a very silly reason, I started playing FarmVille on Facebook with my friends and it reminded me of my favorite game SimCity.

What I like most about the game is how it runs on an iframe, is able to send requests to all the FB friends and keeps the FB session alive even though I haven’t clicked outside of the FarmVille iframe in a long time. It’s not as sophisticated as SimCity, but lets’ wait till it evolves…

A few months ago I was evaluating web frameworks with several criteria. The main one was the ability to extend the web application without the need to recompile and deploy the existing modules.

There are two main concepts for applications in general that save up a great deal of time in testing and deploying (in maintenance in general)

Composite: Composition strategies determine how you manage
component dependencies and the interactions between
components.

Modularity: is designing a system that is divided into a set of functional units (named modules) that can be composed into a larger application. A module represents a set of related concerns. It can include components, such as views or business logic, and pieces of infrastructure, such as services for logging or authenticating users. Modules are independent of one another but can communicate with each other in a loosely coupled fashion.

The following are specific guidelines for developing a modular system:

  • Modules should be opaque to the rest of the system and initialized through a well-known interface.
  • Modules should not directly reference one another or the application that loaded them.
  • Modules should use services to communicate with the application or with other modules.
  • Modules should not be responsible for managing their dependencies. These dependencies should be provided externally, for example, through dependency injection.
  • Modules should not rely on static methods that can inhibit testability.
  • Modules should support being added and removed from the system in a pluggable fashion.

In an old post I was complaining about how in two of the ASP.NET frameworks that I was evaluating I couldn’t separate the modules that had an UI component and deploy them independently of the main application. I was mainly talking of WCSF and Spring.NET.

In WCSF, even though modules can be groups of MVP triads, the main web project still has to be modified each time a new module is added to the application as it contains the shared UI elements (aspx pages or ascx controls). When I tried the WCSF Modularity QuickStart I realized all of the web pages (aspx) are kept into the main web project and the rest of the projects are dlls without any visual part, only the interfaces to the views that are stored on the main web project (IViews.cs). To me, that couples the main web project with each module… It is not true modularity. See the description of the QuickStart here.

For Spring.NET the framework, as any DI framework, allows you to replace your BLL or DAL objects using configuration files as long as the implement the same contract (have the same interface), but there is no concept of module and no way to “plug in” a module containing aspx pages.

I spent some time looking into the Facebook API, after all, they do have a production implementation that complies with all the bullet points under Modularity (see above) During this “read and research” I came across two very good articles on cross browser communication:

Secure Cross-Domain Communication in the Browser by Danny Thorpe
and
Cross Domain Communication with IFrames on this blog.

Why jumping into Cross Browser Communication? Well, if I want to compose an application of different applications running on iframes I better read about Cross Browser Communication…

I decided to expose my ignorance and ask Danny Thorpe for advice, what the hell, he worked on the VCL, Windows Live, CoolIris <... and keep inserting cool projects here...> so he must know what he’s doing.

I emailed him on FB:

I do like the idea of FB where an application hosted on a different domain can interact with the facebook user, facebook sends the auth key, session key and signature and the application calls the facebook servers to perform actions on that user, whether getting the list of friends, send notifications, upload pictures etc. All these actions take place in the application’s servers doing requests to the FB servers and updating the application page on the iFrame running on facebook.

I’ve been trying to move away from the idea, mostly based on the fact that an enterprise application would need to share context (session) between its different modules and that transactions involving several modules might be too difficult.

I’m basing my devil’s advocate argument on your article and trying to state that facebook applications can indeed leave the user’s data on facebook servers on an inconsistent state, due to the different sessions that are not shared.

and Danny Thorpe was kind enough to reply:


Facebook does offer server to server data sharing as you describe, but most Facebook applications actually use client-side cross domain communications using an independent implementation of the iframe cross-domain channel I described in the article. I haven’t studied the Facebook api closely, but I have been informed by folks who have that there is some client-side cross domain communications going on in there.

I agree that sharing user context between modules in different domains in an enterprise application is a scary prospect. I don’t think the issue is with maintaining consistent state as with simple security and privacy issues.

There are other ways to allow multiple applications/domains to access a shared user resource. Delegated authorization is one technique sprouting up from several vendors, including Microsoft. The idea is that app A can be granted access to the user data on server B by the end user without disclosing the user’s login credentials. Server B issues a unique opaque token to App A representing the permissions granted by the end user. The token is unique to the user and application but does not disclose the user’s identity. App A stores the token and can then make requests of server B with that token attached, and server B will look up the token to see what permissions it grants and to see if it has been revoked by the user. The user can revoke the token independently of App A at any time.

Delegated authorization gives the appearance of single-sign-on even across disparate services with incompatible authorization domains. The user has control of granting and revoking access to their information. Multiple applications can connect to the shared resource to monitor state changes, avoiding the issue of inconsistent state.

In order to keep the look and feel of the different applications that compose a portal, I would have to share a site map, the ability to create a unique profile of the user and the look and feel or CSS of the different applications.

Now I’m facing the fork on the path:

  • iFrames with cross domain communication to compose a portal with modules
  • SSO and shared SiteMap and Profile API along with consistent design and CSS to glue the different modules.

more ramblings to follow…

L.

Triple hop issue with ASP.NET delegation Part II: Fixing our remote users.

Where did I left the previous part?… ah yes, our Terminal Server users. Well the XP users were okay and happy but the remote users were not… what could possibly be different for both?

First, the OS, our remote users connect to windows servers (Windows 2000 Standard servers ) so we checked the kerberos.dll version and nope, everything was up to date…

We also checked the kerberos tickets for the logged user and there they were…We again checked our SPN on the domain (setspn), both the SQL Server service and our web service URL were registered in AD with the proper ports.

With the help of a tech support call we landed on this KB article:
Unable to negotiate Kerberos authentication after upgrading to Internet Explorer 6

Windows Server 2000 ships with Internet Explorer 5, it turns out that when IE5 is upgraded to IE6 the advanced option Enabled Integrated Security Option (requires restart) is checked off by default. This option is normally checked on on Windows Server 2003, Windows XP, Vista and 2008.

It turns out that this setting indicates to IE to use NTML as the authentication protocol when the option is unchecked.

This option is equivalent to the following registry key:

HKEY_CURRENT_USER\Software\Microsoft\Windows
\CurrentVersion\Internet Settings

and administrators can enable Integrated Windows Authentication by setting the EnableNegotiate DWORD value to 1

The name of the option is very misleading. You can find more information on this setting here, unfortunately I didn’t find much on the official Microsoft curriculum.

On our web server, we do not allow protocol transition which means the authenticated user should use Kerberos in order to enable the credentials to be delegated to a second hop:

The PROBLEM:

With the client set up to disable Kerberos authentication and with the IIS box set up to disable protocol transition, the credentials passed to the back end were not the end user credentials. Challenge protocols such as NTML do not allow delegation of credentials to a second hop.
A great article regarding the difference between Kerberos and the NTLM, WWW-Authentication such as Basic, Digest etc can be found on Larry Osterman “the Ping of Death”‘s amazing blog post.

The SOLUTION:

Enabling Protocol Transition on our web box at the domain controller would have done the trick:

Or setting up a Group Policy for our end users to have the IE setting checked up. See how to create a Group Policy here.

Cheers!