Tag Archives: Security

Wanted: Senior Software Engineer / Lead [Manila]

Title: Senior Software Engineer / Lead

Location: Manila

Languages: English

 

Who we are

GlobalSign was formed in 1996 as one of the Internet’s original trust service providers (you probably know us as a Certificate Authority). Over the years we have issued millions of digital certificates that have been used to secure commerce and communication on the Internet. Our solutions take the pain out of using cryptography and help organizations solve complex problems with increased productivity and peace of mind.

 

What we’re going to do

The web has changed a lot since 1996 but how we bootstrap trust on it has not changed much – we are going to fix that.

 

Who we’re looking for

We are building a small engineering team here in Manila and need a senior developer with leadership experience who is passionate about security and creating beautiful user experiences.

We want someone who feels someone who feels comfortable on both the front- and back-end, who loves learning new stuff, who’s entrepreneurial, a technical leader, a true creative problem solver.

As a Senior Software Engineer and lead, you’ll write help us recruit and manage new team members and build our engineering team to into a powerhouse. You’ll design and build high-volume web services, amazing user experiences and interact with the open source community.

 

Skills & Experience

  • HTML/CSS/Javascript (jQuery, AJAX, etc.) master with a healthy interest in HTML5, REST and JSON.
  • Experience with one or more server-side languages and frameworks especially Java, Node.js and PHP.
  • Experience designing highly interactive web applications with performance, scalability, usability, and security in mind.
  • Experience with relational database schema design and queries.
  • Experience developing software on Unix/Linux.
  • Love your version control (Git preferably).
  • Understanding of applied cryptographic concepts such as certificates, certificate chains, key management.
  • Understanding of security risks and secure software development.
  • Enjoys prototyping and iterating stuff.
  • Bonus points for speaking Japanese.

 

Required Qualifications

  • 5 years dynamic / scripting language programming, with background in Java and C++ programming preferred.
  • 2+ years experience in Systems Engineering / Administration with firm understanding of *nix architecture.
  • 2+ years experience as a technical lead / manager.
  • Strong Computer Science fundamentals (data structures and algorithms).
  • Bachelor’s degree in Computer Science, or equivalent experience. Engineering or related discipline highly recommended.
  • Awesomeness trumps all other requirements.

 

If this sounds like it could be you, send us a CV and some examples of the work that you’re most proud of.

 

GlobalSign is an equal opportunity employer with locations all over the world. Aside from being a great place to work we offer an excellent benefit package that includes Health, Dental, 401k, Life Insurance, and a generous time off and holiday schedule.

All applicants will be considered without regard to race, color, religion, sex, national origin, age, marital or veteran status; medical condition, disability; or any other legally protected status.

Wanted: Information Technology Manager [Tokyo]

Title: Information Technology Manager

Location: Tokyo, Japan

Languages: English and Japanese

 

Who we are

GlobalSign was formed in 1996 as one of the Internet’s original trust service providers (you probably know us as a Certificate Authority). Over the years we have issued millions of digital certificates that have been used to secure commerce and communication on the Internet. Our solutions take the pain out of using cryptography and help organizations solve complex problems with increased productivity and peace of mind.

 

Who we’re looking for

We are looking for a seasoned Information Technology manager with a background in security. For the right candidate this is an amazing opportunity to report directly to the CTO and build a small team chartered to design, build and manage a global information technology program.

 

What they will do

  • Create a clear technology roadmap connecting vision to technology including setting aggressive but realistic project schedules.
  • Identify, evaluate and select new and emerging technologies that can be assimilated within the company and significantly improve competitiveness.
  • Hire, manage and train a small team made up of one direct and several remote dotted-line professionals in offices in the United States, United Kingdom and the Philippines.
  • Build a team culture where growth is encouraged; you will both train and mentor your team and develop a positive team moral and culture.
  • Work closely with global business leaders across the company to direct technological research through awareness of organization goals, strategies, practices, and user projects.
  • Architect, deploy and manage the operation of secure, reliable and cost-effective IT and telephone infrastructure.
  • Author and maintain policy, processes and procedures to train staff and ensure the smooth delivery of IT services.
  • Regularly report on service availability, reliability and security.
  • Participate in disaster recovery and business continuity exercises.
  • Contribute technically for all aspects of system management, including troubleshooting when required.
  • Perform product and service evaluations to select best products to meet operational and budget requirements. As well as manage vendor relationships and negotiate associated contracts.
  • Establish, track and enforc organization, IT, and financial goals and metrics.

 

Skills & Experience

  • At least two years’ experience in lead or management role in a small to medium enterprise.
  • MCSE or similar certification is desirable.
  • Experience designing, deploying and managing Active Directory and DNS in a global environment.
  • Experience designing, deploying and managing secure network infrastructure including 802.1x, RADIUS, VLANs, Firewalls and remote access.
  • Experience with Anti-Virus, Back-Up and Security Suites.
  • Required to carry duty mobile and response to urgent calls.
  • Occasional travel to international offices.
  • Strong written and oral communication skills required.
  • Preference for experience using virtualization.
  • Strong preference for applicants with experience with security.

 

GlobalSign is an equal opportunity employer with locations all over the world. Aside from being a great place to work we offer an excellent benefit package that includes Health, Dental, 401k, Life Insurance, and a generous time off and holiday schedule.

All applicants will be considered without regard to race, color, religion, sex, national origin, age, marital or veteran status; medical condition, disability; or any other legally protected status.

 

Keywords:

Patch Management, Antivirus, Firewalls, IDS, IPS, AD, DNS, RADIUS, 802.1x, EAP, VPN, IPSEC, Active Directory, Smart Cards, Two Factor Login, Windows, Unix, Linux, Antivirus, Active Directory

 

 

Wanted: Network and System Specialist [Singapore]

Title: Network and System Specialist

Location: Singapore

Languages: English, Japanese is a plus.

 

Who we are

GlobalSign was formed in 1996 as one of the Internet’s original trust service providers (you probably know us as a Certificate Authority). Over the years we have issued millions of digital certificates that have been used to secure commerce and communication on the Internet. Our solutions take the pain out of using cryptography and help organizations solve complex problems with increased productivity and peace of mind.

 

Who we’re looking for

We are looking for an up-and-coming system administrator with a passion for security. For the right candidate this is an amazing opportunity to build and operate a high-availability secure system to power modern web applications

 

What they will do

  • Administration and maintenance of network and system infrastructure including: Maintain service availability, reliability, performance and facilitate incident response
    • Network equipment (Routers, Switches , Firewall / IPS).
    • Load balancers, proxy Servers and web servers.
    • Unix hosts (Redhat) and Databases (SQL).
  • Hardening and monitoring of security of hosts and network devices.
  • Ensure that the network is operating at optimum performance and with high availability by continually reviewing areas of improvement.Support disaster recovering and business continuity exercises.
    • Recommend the optimum or alternative solutions.
    • Monitor and maintain service availability.
    • Ensure procedures are documented.
    • Ensure compliance to policies and procedures.
    • Follow up on requests, deployments & incidents/issues (including escalation) and ensure proper and timely closure.
  • Ability to diagnose and troubleshoot performance, and reliability of all aspects of system.
  • Development and deployment of automation of common tasks.

 

Skills & Experience

  • At least two years’ experience in a similar role.
  • Ability to work in a team and individually.
  • Ability to multi-task and work in a fast pace environment
  • Prior experience maintaining up-to-date operation and procedure documentation.
  • Candidate able to work extended hours and weekends
  • Required to carry duty Mobile and response to urgent calls
  • Strong preference for applicants with experience with PKI and cryptographic key management.
  • Preference for experience using virtualization.
  • Preference for applicants with experience working in a high-availability environment with %99.999 up-time.

 

GlobalSign is an equal opportunity employer with locations all over the world. Aside from being a great place to work we offer an excellent benefit package that includes Health, Dental, 401k, Life Insurance, and a generous time off and holiday schedule.

All applicants will be considered without regard to race, color, religion, sex, national origin, age, marital or veteran status; medical condition, disability; or any other legally protected status.

 

Wanted: Software Engineer [Seattle/Manila]

Title: Software Engineer

Location: Greater Seattle Area and Manila

Languages: English

 

Who we are

GlobalSign was formed in 1996 as one of the Internet’s original trust service providers (you probably know us as a Certificate Authority). Over the years we have issued millions of digital certificates that have been used to secure commerce and communication on the Internet. Our solutions take the pain out of using cryptography and help organizations solve complex problems with increased productivity and peace of mind.

 

What we’re going to do

The web has changed a lot since 1996 but how we bootstrap trust on it has not changed much – we are going to fix that.

 

Who we’re looking for

We are building a small engineering team here in the Seattle area and another in Manila and need developers who feel comfortable on both the front- and back-end. People who love learning new stuff, self-starters — true creative problem solvers.

We want someone who feels knows behavior between and across browsers, best practices, and when and it and is not okay to use an OnClick event.

Someone who believes tested code is happy code, that when done right security can enable new scenarios, that APIs should be easy to consume and that a well thought out platform is significant part of a projects success.

 

Skills & Experience

  • HTML/CSS/Javascript (jQuery, AJAX, etc.) with a healthy interest in HTML5, REST and JSON.
  • Experience with one or more server-side languages and frameworks especially Java, Node.js and PHP.
  • Interest in developing highly interactive web applications with performance, scalability, and usability in mind.
  • Experience working with Linux, Apache, and relational databases. Bonus points for having written your own stored procedure before.
  • Experience developing software in a professional environment, including source control, bug tracking, unit testing
  • Understanding of security risks and secure software development.
  • Understanding of the similarities and differences across browsers (both young and old).
  • Love your version control (Git preferably).
  • Enjoys prototyping and iterating stuff.
  • Bonus points for speaking Japanese.

 

Required Qualifications

  • 2 years dynamic / scripting language programming, with background in Java and C++ programming preferred.
  • 1+ years experience in Systems Engineering / Administration with firm understanding of *nix architecture.
  • Bachelor’s degree in Computer Science, or equivalent experience. Engineering or related discipline highly recommended.
  • Awesomeness trumps all other requirements.

 

If this sounds like it could be you, send us a CV and some examples of the work that you’re most proud of.

 

GlobalSign is an equal opportunity employer with locations all over the world. Aside from being a great place to work we offer an excellent benefit package that includes Health, Dental, 401k, Life Insurance, and a generous time off and holiday schedule.

All applicants will be considered without regard to race, color, religion, sex, national origin, age, marital or veteran status; medical condition, disability; or any other legally protected status.

 

Wanted: Senior Software Engineer (Front-End) [Seattle]

Title: Senior Software Engineer (Front-End)

Location: Greater Seattle Area

Languages: English

 

Who we are

GlobalSign was formed in 1996 as one of the Internet’s original trust service providers (you probably know us as a Certificate Authority). Over the years we have issued millions of digital certificates that have been used to secure commerce and communication on the Internet. Our solutions take the pain out of using cryptography and help organizations solve complex problems with increased productivity and peace of mind.

 

What we’re going to do

The web has changed a lot since 1996 but how we bootstrap trust on it has not changed much – we are going to fix that.

 

Who we’re looking for

We are building a small engineering team here in the Seattle area and need a senior developer who is passionate about security and creating beautiful user experiences. In this role you’ll be able to use your experience to help us recruit new team members and build our engineering team to into a powerhouse.

We want someone who feels someone who feels comfortable on both the front- and back-end, who loves learning new stuff, who’s entrepreneurial, a technical leader, a true creative problem solver.

You’ll have experience with security technologies but your background will be focused on building experiences that bridge the gap between user needs and technology requirements. You’ll also have experience building fault-tolerant, high performance, and highly scalable systems.

 

Skills & Experience

  • HTML/CSS/Javascript (jQuery, AJAX, etc.) master with a healthy interest in HTML5, REST and JSON.
  • Experience with one or more server-side languages and frameworks especially Java, Node.js and PHP.
  • Experience designing highly interactive web applications with performance, scalability, usability, and security in mind.
  • Experience with relational database schema design and queries.
  • Experience developing software on Unix/Linux.
  • Love your version control (Git preferably).
  • Understanding of applied cryptographic concepts such as certificates, certificate chains, key management.
  • Understanding of security risks and secure software development.
  • Enjoys prototyping and iterating stuff.Bonus points for speaking Japanese.

 

Required Qualifications

  • 5 years dynamic / scripting language programming, with background in C/C++ systems programming preferred.
  • 2+ years experience in Systems Engineering / Administration with firm understanding of *nix architecture.
  • Strong Computer Science fundamentals (data structures and algorithms).
  • Bachelor’s degree in Computer Science, or equivalent experience. Engineering or related discipline highly recommended.
  • Awesomeness trumps all other requirements.

 

If this sounds like it could be you, send us a CV and some examples of the work that you’re most proud of.

 

GlobalSign is an equal opportunity employer with locations all over the world. Aside from being a great place to work we offer an excellent benefit package that includes Health, Dental, 401k, Life Insurance, and a generous time off and holiday schedule.

All applicants will be considered without regard to race, color, religion, sex, national origin, age, marital or veteran status; medical condition, disability; or any other legally protected status.

A look at the new Windows Update SSL certificates

This morning I noticed a tweet by Mikko about the Windows Update certificate chain looking odd so I decided to take a look myself.

I started with the webserver configuration using SSLLABS, unfortunately it did not fare well:

Looking a little closer we see a few things of interest:

  • SSLLABS is unable to validate the certificate
  • The server is using weak ciphers
  • The server is vulnerable to the BEAST attack
  • The server is not using an Extended Validation  (EV) Certificate
  • The server is supporting SSL 2.0

To understand the specifics here we needed to look a little deeper, the OpenSSL s_client is a great tool for this:

openssl s_client –showcerts -status –connect www.update.microsoft.com:443

Loading ‘screen’ into random state – done

CONNECTED(0000017C)

OCSP response: no response sent

depth=1 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Update Secure Server CA 1

verify error:num=20:unable to get local issuer certificate

verify return:0

Certificate chain

0 s:/C=US/ST=Washington/L=Redmond/O=Microsoft/OU=WUPDS/CN=www.update.microsoft.com

i:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Update Secure Server CA 1

1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Update Secure Server CA 1

i:/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority

Server certificate

—–BEGIN CERTIFICATE—–

MIIF4TCCA8mgAwIBAgITMwAAAAPxs7enAjT5gQAAAAAAAzANBgkqhkiG9w0BAQUF

—–END CERTIFICATE—–

1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Update S

ecure Server CA 1

i:/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority

—–BEGIN CERTIFICATE—–

MIIGwDCCBKigAwIBAgITMwAAADTNCXaXRxx1YwAAAAAANDANBgkqhkiG9w0BAQUF

—–END CERTIFICATE—–

subject=/C=US/ST=Washington/L=Redmond/O=Microsoft/OU=WUPDS/CN=www.update.microsoft.com issuer=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Update

Secure Server CA 1

No client certificate CA names sent

SSL handshake has read 3403 bytes and written 536 bytes

New, TLSv1/SSLv3, Cipher is AES128-SHA

Server public key is 2048 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol  : TLSv1

Cipher    : AES128-SHA

Session-ID: 33240000580DB2DE3D476EDAF84BEF7B357988A66A05249F71F4B7C90AB62986

 

Session-ID-ctx:

Master-Key: BD56664815654CA31DF75E7D6C35BD43D03186A2BDA4071CE188DF3AA296B1F9674BE721C90109179749AF2D7F1F6EE5

Key-Arg   : None

PSK identity: None

PSK identity hint: None

Start Time: 1339954151

Timeout   : 300 (sec)

Verify return code: 20 (unable to get local issuer certificate)

read:errno=10054

 

With this detail we can also look at the certificates with the Windows Certificate viewer, we just extract the server certificate Base64 and put it into a text file with a .cer extension and open it with Explorer:

   
   
   

 

From these we see a few additional things:

  • OCSP Stapling is not enabled on the server
  • The issuing CA was created on 5/30/2012 at 8:49pm
  • The issuing CA was issued by the 2001 SHA1 “Microsoft Root Authority”

So with this extra information let’s tackle each of these observations and see what conclusions we come to.

 

SSLLABS is unable to validate the certificate; there are two possible reasons:

a. The server isn’t including the intermediate certificates (it is) and SSLLABS doesn’t chase intermediates specified in the AIA:IssuerCert extension (doubt it does) or that extension isn’t present (it is).

b. The Root CA isn’t trusted by SSLLABS (which appears to be the case here).

My guess based on this is that Ivan only included the certificates in the “Third-Party Root Certification Authorities” store and did not include those in the “Trusted Root Certification Authorities” which are required for Windows to work.

Basically he never expected these Roots to be used to authenticate a public website.

[2:00 PM 6/18/2012] Ivan has confirmed he currently only checks the Mozilla trusted roots, therefor this root wouldn’t be trusted by SSLLABS.

Microsoft’s decision to use this roots means that any browser that doesn’t use the CryptoAPI certificate validation functions (Safari, Opera, Chrome on non-Windows platforms, Firefox, etc.) will fail to validate this certificate.

This was probably done to allow them to do pinning using the “Microsoft” policy in CertVerifyCertificateChainPolicy.

I believe this was not the right approach since I think it’s probably legitimate to use another browser to download patches.

[2:00 PM 6/18/2012] The assumption in this statement (and it may turn out I am wrong) is that it is possible for someone to reach a path where from a browser they can download patches; its my understanding this is an experience that XP machines using a different browser have when visiting this URL I — I have not verified this.

[3:00 PM 6/18/2012] Harry says that you have not been able to download from these URLs without IE ever, so this would be a non-issue if that is the case.

To address this Microsoft would need to either:

  • Have their PKI operate in accordance with the requirements that other CAs have to meet and be audited and be found to meet the requirements of each of the root programs that are out there.
  • Have two separate URLs and certificate chains one for the website anchored under a publicly trusted CA and another under this private “Product” root. The manifests would be downloaded from the “Product” root backed host and the web experience would be from the “Public” root backed host.
  • Cross certifying the issuing CA “Microsoft Update Secure Server CA 1” under a public CA also (cross certification), for example under their IT root that is publically trusted and include that intermediate in the web server configuration also. Then have a CertVerifyCertificateChainPolicy implementation that checks for that CA instead of the “Product” roots.

 

The server is using weak ciphers; the server is using several weak ciphers:


I see no reason to support the MD5 based ciphers as I find it hard to believe that there are any clients that can communicate with this site that do not support their SHA1 equivalents.

 

[2:00 PM 6/18/2012] I have been told I am too critical by calling these MD5 based ciphers as weak in that they are used as HMAC, it is true that when used with a key as is the case with HMAC the current attacks are not relevant. With that said any client that supports these suites will also support their SHA1 counterpart and there is no reason to support the weaker suites that use MD5.

 

The server is vulnerable to the BEAST attack; and SSLLABS isn’t able to tell if the server is specifying a cipher suite preference, this means it probably is not.

It is the cipher suite ordering issue that is actually resulting in the warning about the BEAST attack though. It is addressed by putting RC4 cipher suites at the top of the cipher suite order list.

[2:00 PM 6/18/2012] It’s been argued the BEAST attack isn’t relevant here because the client is normally not a browser, these pages that are returned do contain JS and there are cases where users visit it via the browser — otherwise there would not be HTML and JS in them. As such the attacker could use the attack to influence you to install malicious content as if it came from Microsoft. Maybe its not a leakage of personal information initially but its an issue.

 

It is not using an Extended Validation (EV) Certificate; this is an odd one, is an EV certificates necessary when someone is attesting to their own identity? Technically I would argue no, however no one can reasonably expect a user to go and look at a certificate chain and be knowledgeable enough to that this is what is going on.

The only mechanism to communicate the identity to the user in as clear a way is to make the certificate be an EV certificate.

Microsoft really should re-issue this certificate as an EV certificate – if there was ever a case to be sure who you are talking to it would certainly include when you are installing kernel mode drivers.

 

The server is supporting SSL 2.0; this also has to be an oversight in the servers configuration of SSL 2.0 has been known to have numerous security issues for some time.

They need to disable this weak version of SSL.

 

OCSP Stapling is not enabled on the server; OCSP stapling allows a webserver to send its own revocations status along with its certificate improving performance, reliability and privacy for revocation checking. According to Netcraft Windows Update is running on IIS 7 which supports it by default.

This means Microsoft is either not allowing these web servers to make outbound connections or they have explicitly disabled this feature (login.live.com has it enabled and working). While it is not a security issue per-se enabling it certainly is a best practice and since it’s on by default it seems they are intentionally not doing it for some reason.

 

The issuing CA was created on 5/30/2012 at 8:49pm; this isn’t a security issue but it’s interesting that the issuing CA was created four days before the Flame Security advisory. It was a late night for the folks operating the CA.

 

That’s it for now,

 

Ryan

What is your organizations policy on SSL?

In other posts I discussed how to redirect the initial request to a website from the HTTP version to the HTTPS  (for Apache and IIS).

By following those steps your website no longer will serve HTTP content but users will still be able to get to your site without having to know to type the HTTPS:\\ before they browse to your site.

This is an important part of making your site reachable by users over SSL because:

  1. Most users do not type a URL moniker at all when entering an URL.
  2. Since 99% of the traffic on the Internet is not available over HTTPS so browsers default to HTTP.
  3. Existing HTTP URLs that have been indexed by search engines, embedded in documents, passed off in emails can continue to work.

This approach isn’t perfect, for example:

  1. An attacker can perform a Man-In-The-Middle on the initial request and bypass the SSL protection (see sslstrip).
  2. It has the potential to “train users” to not navigate to the HTTPs version of your site initially.

The problem is of course that the alternative of returning an error when a user requests the HTTP version of the website (say a 403.4 – SSL required) or simply not having a server listening on the HTTP port is almost the same as saying your site isn’t accessible to the mainstream users.

So how can you manage these problems? There are a few things you can do:

For sensitive services like those for login and those that collect personal information or credit cards actually use 403.4 errors. This tells the user in no uncertain terms that SSL is required for that task but since the browsing experience does not typically “start here” you do break the user experience for your users.

You may also want to consider hosting the most sensitive content like login and account details on a separate virtual host that does not have a HTTP listener (for example login.example.com or accounts.example.com).

Next you should communicate your policy on SSL to the web browsers so they can do the right thing for the users, there are several ways for you to do this:

  1. Set the HTTP Strict-Transport-Security (HSTS) header for your pages this will tell the browsers to require SSL on your site.
  2. Request that your site be added to the HTTPS Everywhere Rule list.
  3. Request that your site be added to the Preloaded HSTS list in Google Chrome.
  4. If you are a larger site you can also request that Google “pin” your web server’s public keys to your domain.

These things will not eliminate these risks but it does help, especially for those using browsers that support HSTS (Chrome and Firefox as of today) or those that are using plugins like HTTPS Everywhere and NoScript.

As for the last two, they are clearly Chrome specific but it represents about 32% of the browser market today and as such is worth paying attention to.

Ryan

Additional Resources

How to Deploy HTTPS Correctly

 

Redirecting HTTP to HTTPS in IIS

So you have been using SSL on your IIS 7.5 or greater server for some time now; to get here you had to do a few things:

  1. You scrubbed your site content to ensure all URLs are using their relative form, e.g. “src=’//images\image.png” or explicitly reference the use of HTTPS.
  2. You have tested for certificate and SSL related problems like mixed content, appropriately tagging cookies as secure.
  3. You have ensured that you follow the best practices guidance for SSL server configuration and verified you get an A on  SSLLabs.

Are you done? Not yet there are a few things left for you to do, the most obvious being redirecting all traffic to the SSL version of your site!

This is easy enough to accomplish but before you do so you should probably monitor your CPU usage during your peak so to ensure you have some headroom. This isn’t likely to be a problem as most web-servers are not CPU bound but it’s always good to check.

Once you know you are OK then it’s just a matter of deciding which approach to use, you have two choices:

  1. Dynamically rewriting via code in your ASPX pages
  2. Using the IIS URL Rewrite  module

If you are familiar with the IIS configuration you’re probably asking yourself what about the “Require secure channel (SSL)” option in the IIS MMC? Unfortunately this doesn’t do redirecting it only requires the use of SSL on a given site/folder/file.

So how do you decide which approach to use? The answer to that question is dependent on both your environment and personal preference.

For example if 100% of your site is ASPX based (no static HTML), you have your code structured so that there is a common include and you are not already using the URL Rewrite module I would use method one based on KB239875.

I suspect that these conditions will not be met for most people so let’s focus on method two, using the URL Rewrite  module.

This approach has a number of benefits, for one having this module allows you to leverage remapping for other purposes also for example maintaining old links that have SEO value. From a security standpoint it’s also a good approach as it keeps this decision one of policy that is enforced in a central place.

To use the URL rewrite approach you will need to do the following:

 

1. Install the URL Rewrite module (x86, x64).

2. Add a rule to rewrite all HTTP URLs to HTTPS.

a. Open your “web.config” with your favorite editor.

b. Find the “configuration\system.webserver\rewrite\rules” section.

c. Add the following text block:

<rule name=”Redirect to HTTPS” stopProcessing=”true”>

<match url=”(.*)” />

<conditions>

<add input=”{HTTPS}” pattern=”^OFF$” />

</conditions>

<action type=”Redirect” url=”https://{HTTP_HOST}/{R:1}” redirectType=”Permanent” />

</rule>

3. Restart IIS.

Now just go to your website over HTTP and you will see you are redirected to the HTTPS instance of the site.

 

Ryan

Additional Resources

IIS Rewrite Module Configuration Reference

10 URL Rewriting Tips and Tricks

Automatically redirect HTTP requests to HTTPS on IIS7 using URL Rewrite 2.0

 

 

Was the Flame WSUS attack caused just because of the use of MD5?

This morning I saw a number of posts on Twitter about Flame and the attacks use of a collision attack against MD5.

This flurry of posts was brought on about by Venafi, they have good tools for enterprises for assessing what certificates they have in their environments, what algorithms are used, when the certificates expire, etc. These tools are also part of their suite used for certificate management.

They published some statistics on the usage of MD5, specifically they say they see MD5 in 17.4% of the certificates seen by their assessment tools. Their assessment tool can be thought of as a combination of nmap and sslyze with a reporting module.

Based on this we can assume the certificates they found are limited to SSL certificates, this by itself is interesting but not indicative of being vulnerable to the same attack that was used by Flame in this case.

 

 

Don’t get me wrong Microsoft absolutely should not have been issuing certificates signed using MD5 but the collision was not caused (at least exclusively) by their use of MD5; it was a union of:

  1. Use of non-random serial numbers
  2. Use of 512 bit RSA keys
  3. Use of MD5 as a hashing algorithm
  4. Poorly thought out certificate profiles

If any one of these things changed the attack would have become more difficult, additionally if they had their PKI thought out well the only thing at risk would have been their license revenue.

If it was strictly about MD5 Microsoft’s announcement the other day about blocking RSA keys smaller than 1024 bit would have also included MD5 – but it did not.

So what does this mean for you? Well you shouldn’t be using MD5 and if you are you should stop and question your vendors who are sending you down the path of doing so but you also need to take a holistic look at your use of PKI and make sure you are actually using best practices (key length, serial numbers, etc). With that said the sky is not falling, walk don’t run to the nearest fire escape.

Ryan

RSA keys under 1024 bits and you

Recently Microsoft announced that they will push an update in August that will prevent the use of RSA keys with a bit-length less than 1024.

This has been a change that has been coming for some time, for example Microsoft has not allowed CAs with such small keys in their root program for quite a while. They have been proponents of the key length restrictions in the current Baseline Requirements for SSL/TLS certificates in the CA/Browser Forum.

Despite this the SSL Pulse project still shows that within the top 1 million websites there are still web servers using keys less than 1024 bits in size (5 of them). While I do not know who the issuers of these certificates are (they are not GlobalSign), the Microsoft Root Program had prohibited the issuance of smaller than 1024 bit keys and the new Baseline requirements require that all certificates 1024 bits in length expire before December 2013 so if my guess is these would have naturally expired by then.

This patch will cause those certificates to fail to validate once applied.

Microsoft is adverse to “breaking things” they do not control; it’s easy to understand why. With that in mind we can we can assume the decision to release this policy in the form of a patch is clearly based on the recent PKI issues used by Flame which was only possible because of a its use of weak crypto.

But what does this mean for you? Well in the context of getting TLS certificates from a CA who is trusted by Microsoft or Mozilla you shouldn’t be impacted at all since no CA should have been issuing certificates with such small keys.

That said in an enterprise it’s certainly possible such certificates exist and if you have an internal PKI you need to ensure they don’t in yours before this patch gets deployed in August or those systems will stop working.

Microsoft provides some guidance on how to look for these certificates but your likely better off running a tool like Venafi Accessor against your environment to find what keys and certificates you have deployed.

They release their “assessment tool” for free as a means to market to you their certificate management products, the marketing material is alarmist (and in some cases a little misleading) but the assessment tool I good and will be useful to organizations who need to understand the implications to their environment.

Ryan