The issue that HSTS addresses is that users tend to type http:// at best, and omit the scheme entirely most of the time. In the latter case, browsers will insert http:// for them.
An attacker can grab that connection, manipulate it and only the most eagle eyed users might notice that it redirected to https://www.bank0famerica.com or some such. From then on, the user is under the control of the attacker, who can intercept passwords etc at will.
An HSTS enabled server can include the following header in an HTTPS reply:
Strict-Transport-Security: max-age=16070400; includeSubDomains
When the browser sees this, it will remember, for the given number of seconds, that the current domain should only be contacted over HTTPS. In the future, if the user types http:// or omits the scheme, HTTPS is the default. In fact, all requests for URLs in the current domain will be redirected to HTTPS. (So you have to make sure that you can serve them all!).
For more details, see the specification at http://tools.ietf.org/html/draft-hodges-strict-transport-sec-02
HSTS is supported in Google Chrome, Firefox 4, and the popular NoScript Firefox extension
Go to chrome://net-internals/#hsts to check your HSTS settings in Google Chrome.
For a more secure web experience…
The practice of hard coding IPv4 addresses creates problems when modifying and existing application to support IPv6 or creating new IP version-independent applications.
The Checkv4.exe utility is designed to provide you with a code porting partner; a utility that steps through your code base with you, identifies potential problems or highlights code that could benefit from IPv6-capable functions or structures, and makes recommendations. With the Checkv4.exe utility, the task of modifying an existing IPv4 application to support IPv6 becomes much easier.
Recommendations for Running Checkv4.exe:
- Acquire the Checkv4.exe utility. The Checkv4.exe utility is installed as part of the Microsoft Windows Software Development Kit (SDK) released for Windows Vista and later. The Windows SDK is available through an MSDN subscription and can also be downloaded from the Microsoft website (http://msdn.microsoft.com).
- Run the Checkv4.exe utility against your code. Learn about how to run the Checkv4.exe utility against your files in the section on Using the Checkv4.exe Utility.
- The Checkv4.exe utility alerts you to the presence of common defines for IPv4 addresses, such as INADDR_LOOPBACK. Modify any code that uses literal strings with code that is protocol-version agnostic.
- Search your code base for other potential literal strings, as appropriate.
The Checkv4.exe utility can help you find common literal strings, but there may be others that are specific to your application. You should perform thorough searching and testing to ensure your code base has eradicated potential problems associated with literal strings.
/Hasain
Server side DirectAccess requires one network adapter to be configures as external with the Public or Private profile to apply the Connection Security rules. With the security connection rules in place the DirectAccess server will be able to offer IPSec authentication and tunneling to the clients.
Recently I was involved in a customer case where the DirectAccess server decided to change the external-facing interface to the domain profile, this caused the server to deactivate all security connection rules and the whole DirectAccess solution to stop working.
Now the decision about the profile type for a network interface in Windows is handled by the Network Location Awareness NLA service. The NLA probes for the possibility to reach the servers domain and if a connection is successful the profile will change to domain and the interface will be categorised as "Intranet Authenticated" according to NLA.
The solution or rather said the reason for the sudden change in the specific customer case was firewall related. The firewall was configured to allow traffic from DMZ, where the DirectAccess server external interface was connected, to the internal domain network, this caused NLA to "see" the domain over the external interface and…. So the solution was simply to configure a deny rule prohibiting the DirectAccess server external IP from accessing internal resources and all was back to normal again!
The following registry location is good help when troubleshooting NLA related problems
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList
/Hasain
