Tag Archives: Security

How to Build Your Own OpenSSL

4 Replies

So you have been reading all the press on forward secrecy and want to deploy it? But does your OpenSSL support it? Thankfully it is easy to tell, just run this command:

> openssl ciphers

If you see ciphers like “ECDHE-RSA-AES256-GCM-SHA384” then you have a version of OpenSSL that was built with ECC and ECDHE support enabled which is required if you want forward secrecy today.

So how do you go about doing this? Thankfully you don’t need to be a developer of cryptographer, with the following commands you should be able to get the latest (as of the time of this post) OpenSSL with ECC and ECDH enabled.

root> cp /usr/bin/openssl /usr/bin/openssl.orig
root> cd /tmp
root> wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz
root> tar -xvzf openssl-1.0.1e.tar.gz
root> cd openssl-1.0.1e
root> ./config no-shared no-threads 
root> make depend
root> make
root> make install

You may also need to re-build your web server,you see even though the latest versions of Nginx and Apache include the necessary changes to enable ECDH if the version you are running was built against a version of OpenSSL that did not include support your going to have to rebuild it also. Here is a quick post on how to do that for Nginx.

 

Good luck!

 

Ryan

Abstract: Revocation reality and the path to becoming effective

1 Reply

Just submitted my first abstract for the NIST workshop on “Workshop on Improving Trust in the Online Marketplace” in April, the title of the talk is “Revocation reality and the path to becoming effective”, the abstract of which is:

 

The concept of certificate revocation is core to the X.509 trust model however 18 years after its introduction the reality is as implemented and deployed it falls short of its promise to enable an issuer certificate issuers to protect relying parties from malicious actors and miss-issuance

This talk will discuss the findings of a project where I have observed the behavior (https://revocation-report.x509labs.com), up time and performance of revocation repositories for a number of commercial Certificate Authorities for a period of over six months.

Additionally I will overview the revocation behavior of the most common browsers, identifying the gaps as they exist in those implementations.

And finally I will provide a set of recommendations that I believe if followed can address the current gaps which would move us to a world where revocation checking is an effective means of protecting relying parties from known bad actors and miss-issuance.

Is SSL Broken?

Leave a reply

[ This is a re-post of a article I wrote for the GlobalSign corporate blog, you can find it here]

It seems every month a new flaw is identified in SSL, and while that’s a slight exaggeration, after a while one starts to ask the question – is SSL broken? My answer would to that question would be no, but the protocol is nearly twenty years old and even though it now carries a new name (TLS) it also carries much of the baggage of the past in its design.

Despite this fact, my faith in TLS is stronger today than it ever was. My reasoning is simple – today we understand the strengths and weaknesses of this protocol better than we ever have. It is continuously reviewed by the world’s best engineers and cryptographers, trying to find the bad assumptions their predecessors made, strengthening it in response to identified weaknesses, and modernizing it to use the strongest forms of cryptography available.

This continuous investment in this foundational technology gives me faith.

Today another attack on TLS was made public.  “Lucky Thirteen” is a derivative of the work of French cryptographer Serge Vaudenay (Padding Oracles against CBC based ciphers – 2010), though unlike Vaudenay’s attack, Lucky Thirteen uses a known Timing Attack previously believed to be impractical. A successful application of this attack enables an attacker to decrypt your SSL communications.

Unlike other recent attacks, such as BEAST,  Lucky Thirteen requires a server-side fix. This means that complete and effective protection against this attack will require all webservers to be updated or patched.

That said, it is possible to mitigate the attack by removing CBC cipher suites, since the attack is against SSL/TLS’s use of CBC. But what to use in its place? The consensus of security researchers is to adopt suites based on AES-GCM, and while I agree, this has one problem – the large population of clients that do not yet support it.

This recommendation is complicated slightly by the BEAST attack from last year, the resolution of which required a client side fix which has, in all likelihood, not yet been deployed ubiquitously. As such, I still recommend prioritizing the older and less secure RC4 based suites above AES-GCM since it addresses both issues.

But should you be worried? It depends. If you are using TLS (and not its little brother DTLS) I would say your best bet is to walk calmly to the nearest exit, and use this as an excuse to ensure you are following industry Best Practices when deploying SSL – if  you’re not, this attack is the least of your worries.  Specifically I would recommend visiting the SSL Configuration Checker and make the critical (red) and important (yellow) configuration changes it suggests.

I would also encourage you to deploy HTTP Strict Transport Security  on your site since the attack this mitigates (SSL stripping) is much easier for an attacker to execute.

The good news is that if you were already following the advice of the SSL Configuration Checker you were prioritizing RC4 over other ciphers and most sessions to your server were resistant to this attack. This doesn’t mean you should not be deploying the patch to this issue, you just don’t need to do so in a crazed rush.

So are there any lessons we can take away from this? Of course there are. As a server operator, I would say this finding underscores the importance of regularly reviewing your server configuration to ensure that it follows industry best, and that you are always operating the most recent and stable release of your web server.

If you want a more technical walk through of this attack, I highly recommend this post by Mathew Green on TLS Timing Oracles or this one by Adam Langly.

What is the status of revocation checking in browsers?

9 Replies

Today we did an announcement of some work we have been doing with CloudFlare to speed up SSL for all of our customers through some improvements to our revocation infrastructure.

One of the things that come up when talking about this is how each of the browsers handles revocation checking, I thought it might be useful to put together a quick post that talks about this to clear up some confusion.

The first thing that’s important to understand is that all major browsers do some form of revocation checking, that includes Opera, Safari, Chrome, Firefox and Internet Explorer.

Let’s talk about what that means, the IETF standards for X.509 certificates define three ways for revocation checking to be done, the first is Certificate Revocation Lists (CRLs), next there is the Online Certificate Status Protocol (OCSP) and finally there is something called Simple Certificate Validation Protocol (SCVP).

In the context of browsers we can ignore SCVP as no browser implements them; this leaves us with CRLs and OCSP as the standards compliant ways of doing revocation checking.

All of the above browsers support these mechanisms, in addition to these standard mechanisms Google has defined a proprietary certificate revocation checking scheme called CRLsets.

If we look at StatCounter for browser market share that means today at least 64.84% (its likely more) of the browsers out there are doing revocation checking based on either OCSP or CRLs by default.

This means that when a user visits a website protected with SSL it has to do at least one DNS look-up, one TCP socket and one HTTP transaction to validate the certificate the web server presents and more likely several of these.

This is important because of the way revocation checking needs to be done, you need to know if the server you are talking to really is who they say they are before you start to trust them – that’s why when browsers do OCSP and CRLs they do this validation before they download the content from the web page.

This means that your content won’t be displayed to the user until this check happens and this can take quite a while.

For example in the case of IE and Chrome (when it does standards based revocation checking on Windows) it uses CryptoAPI which will time-out after 15 seconds of attempting to check the status of a certificate.

The scary part is that calls to this API do actually time out and when they do this delay is experienced by the users of your website!

So what can you do about it? It’s simple really you have to be mindful of the operational capacity and performance of the certificate authority you get your certificate from.

Check out this monitoring portal I maintain for OCSP and this one I maintain for CRLs, you will see GlobalSign consistently outperforms every other CA for the performance of their revocation infrastructure in most cases it’s nearly 6x as fast and in others is much more than that.

The other thing to understand is that today the default behavior of these browsers when checking the status of a certificate via OCSP or CRLs is to do what is often referred to as a “soft-revocation failure”.

This basically means that if they fail for any reason to check the status of a certificate (usually due to performance or reliability issues) they will treat the certificate as good anyways. This is an artifact of CAs not operating sufficiently performant and reliable infrastructure to allow the browsers to treat network related failures critically.

Each of these browsers all have options you can use to enable “hard” or “strict” revocation checking but until the top CAs operate infrastructure that meets the performance and reliability requirements of the modern web no browser will make these the default.

Finally its also important to understand that even with this “soft-failure” your website experiences the performance cost of doing these checks.

It’s my belief that the changes we have put into place in our own infrastructure meet that bar and I hope the other CAs follow in our lead as it is in the best interest of the Internet.

Ryan

Algorithms, key size and digital certificates

Leave a reply

Introduction

On the surface the digital certificates are not complicated — a third-party (a certificate authority) verifies some evidence and produces a piece of identification that can be presented at a later date to prove that the verification has taken place.

As is usually the case when we look a little deeper things are not that simple. In the this case we have to care about a few other things, for example what are the qualifications of the third-party, what are their practices and what cryptographic algorithms did they use to produce the digital certificate?

As an administrator using digital certificates like in the case of SSL these things also can have impact on your operational environment – by using a certificate from a certificate authority you take dependencies on their practices and operational environment.

This is especially true when it comes to decisions relating to what cryptographic algorithms and key lengths are accepted and used by that third-party.

Thankfully you do not need to be a cryptographer to make good decisions on this topic, first we need to start with an understanding of the history, future and then considerations.

History

In recent history the industry has relied on two algorithms, the first being an encryption algorithm called RSA the second being a hash algorithm called SHA-1. Both of which have are considered weaker now due to advances in cryptanalysis.

RSA’s strength and performance is based on the size of the key used with it, the larger the key the stronger and slower it is.

These advances in cryptanalysis have driven the increase in key size used with this algorithm which in turn has increased the amount of computing power necessary to maintain the same effective strength.

The problem with this is that that every time we double the size of an RSA key the decryption operations with that key become 6-7 times slower.

As a result as of all of this as of January 2011 trustworthy Certificate Authorities have aimed to comply with NIST (National Institute of Standards and Technology) recommendations by ensuring certificates all new RSA certificates have keys of 2048 bits in length or longer.

Unfortunately this ever increasing key size game cannot continue forever, especially if we ever intend do see SSL make up the majority of traffic on the internet – the computational costs are simply too great.

That takes us to SHA-1, hash algorithms take a variable amount of input and reduce it to a typically shorter and fixed length output the goal of which being to provide a unique identifier for that input. The important thing to understand is that hash algorithms are always susceptible to collisions and the advances in the cryptanalysis have made it more likely that such a collision can be made.

The problem here is that there is no parameter to tweak that makes this problem harder for an attacker, the only way to address this issue is to change to a stronger algorithm to produce the hash.

Future

For the last decade or so there has been slow and steady movement towards using two new algorithms to address these advances — SHA-2 and ECC.

ECC has the potential for significant performance benefits over RSA without reducing security and SHA-2 has three versions each with progressively longer lengths which help it both address the current risks and give it some longevity.

Considerations

Our goal in configuring SSL is enabling users to communicate with us securely; to accomplish this goal we need to be able to do this with the fewest hassles, lowest costs and comply with any associated standards.

Interoperability is the key that ensures the fewest hassles — if it was not for this we would simply switch to these new algorithms and be done with it. As is normally the case when it comes to security this is where Windows XP rears its ugly head, SHA-2 was added to XP in Windows XP Service Pack 2 and ECC in Windows Vista.

These facts set the adoption clock for these new algorithms; if you care about XP (about 30% of the Internet today) you can’t adopt ECC and SHA-2 in full for about 5 years.

This leaves us with RSA 2048 and SHA-1 which thankfully is broadly considered sufficient for the next decade.

Performance is always a concern as well — a RSA 2048-bit RSA certificate used in SSL will result in around a 10% CPU overhead not huge but something to keep in mind.

As mentioned previously we can’t forget compliance — whether it is the Payment Card Industry / Data Security Standards (PCI/DSS), Federal Information Processing Standards (FIPS) 140-2 or some other set of criteria you need to meet this always needs to be considered.

Conclusion

The decision of what algorithm’s and key lengths to use in your digital certificates is dependent on a number of factors including security, interoperability, performance and compliance. Each situation may require a different trade-off to be made however a rule of thumb if you stick with SHA-2 and RSA 2048-bit certificates and keys you should be fine for now.

 

Resources

[1]   BlueKrypt Cryptographic Key Length Recommendations

[2]   Recommendation for Key Management, Special Publication 800-57 Part 1 Rev. 3, NIST, 05/2011

[3]   Fact Sheet Suite B Cryptography, NSA, 11/2010

[4]   Worldwide Operating System Statistics, Stat Counter, 9/2012

[5]   RSA Algorithm, Wikipedia

[6]   RSA Key Lengths, Javamex

[7]   ECC Algorithm, Wikipedia

[8]   Performance Analysis of Elliptic Curve Cryptography for SSL, Sun

[9]   Using ECC keys in X509 certificates, UnmitigatedRisk

[10] Using SHA2 based signatures in X509 certificates, UnmitigatedRisk

[11]Payment Card Industry / Data Security Standards – PCI

[12]Federal Information Processing Standards 140-2 – NIST

Government CAs in the Microsoft Root Program

1 Reply

Microsoft was the first Root program in a browser to have an open and transparent process for becoming a CA as well as the first to have public policy, audit and technical requirements that CAs must comply with.

Today while the other browsers have joined on and even raised the bar significantly Microsoft continues to operate their root program in an open and clear way.

One example of this is the list they publish of the companies who meet their requirements; you can see this list here.

There are a number of interesting things we can gleam from this list; one of them is how many governments have their own certificate authorities.

For example as of March 11, 2011 we know that there are a total of 46 government owned and operated “Root Certificates” in the Microsoft Root Program, these include:

Current CA Owner Country Thumbprint
Government of Austria, Austria Telekom-Control Commission Austria e7 07 15 f6 f7 28 36 5b 51 90 e2 71 de e4 c6 5e be ea ca f3
Government of Brazil, Autoridade Certificadora Raiz Brasileira Brazil 8e fd ca bc 93 e6 1e 92 5d 4d 1d ed 18 1a 43 20 a4 67 a1 39
Government of Brazil, Instituto Nacional de Tecnologia da Informação (ITI) Brazil ‎70 5d 2b 45 65 c7 04 7a 54 06 94 a7 9a f7 ab b8 42 bd c1 61
Government of Finland, Population Register Centre Finland fa a7 d9 fb 31 b7 46 f2 00 a8 5e 65 79 76 13 d8 16 e0 63 b5
Government of France France 60 d6 89 74 b5 c2 65 9e 8a 0f c1 88 7c 88 d2 46 69 1b 18 2c
Government of Hong Kong (SAR), Hongkong Post Hong Kong (SAR) d6 da a8 20 8d 09 d2 15 4d 24 b5 2f cb 34 6e b2 58 b2 8a 58
Government of Hong Kong (SAR), Hongkong Post Hong Kong (SAR) e0 92 5e 18 c7 76 5e 22 da bd 94 27 52 9d a6 af 4e 06 64 28
Government of India, Ministry of Communications & Information Technology, Controller of Certifying Authorities (CCA) India 97 22 6a ae 4a 7a 64 a5 9b d1 67 87 f2 7f 84 1c 0a 00 1f d0
Government of Japan, Ministry of Internal Affairs and Communications Japan 96 83 38 f1 13 e3 6a 7b ab dd 08 f7 77 63 91 a6 87 36 58 2e
Government of Japan, Ministry of Internal Affairs and Communications Japan ‎7f 8a b0 cf d0 51 87 6a 66 f3 36 0f 47 c8 8d 8c d3 35 fc 74
Government of Korea, Korea Information Security Agency (KISA) South Korea 5f 4e 1f cf 31 b7 91 3b 85 0b 54 f6 e5 ff 50 1a 2b 6f c6 cf
Government of Korea, Korea Information Security Agency (KISA) South Korea 02 72 68 29 3e 5f 5d 17 aa a4 b3 c3 e6 36 1e 1f 92 57 5e aa
Government of Korea, Korea Information Security Agency (KISA) South Korea f5 c2 7c f5 ff f3 02 9a cf 1a 1a 4b ec 7e e1 96 4c 77 d7 84
Government of Korea, Ministry of Government Administration and Home Affairs (MOGAHA) South Korea 63 4c 3b 02 30 cf 1b 78 b4 56 9f ec f2 c0 4a 86 52 ef ef 0e
Government of Korea, Ministry of Government Administration and Home Affairs (MOGAHA) South Korea 20 cb 59 4f b4 ed d8 95 76 3f d5 25 4e 95 9a 66 74 c6 ee b2
Government of Latvia, Latvian Post Latvia 08 64 18 e9 06 ce e8 9c 23 53 b6 e2 7f bd 9e 74 39 f7 63 16
Government of Latvia, Latvian State Radio & Television Centre (LVRTC) Latvia c9 32 1d e6 b5 a8 26 66 cf 69 71 a1 8a 56 f2 d3 a8 67 56 02
Government of Lithuania, Registru Centras Lithuania 97 1d 34 86 fc 1e 8e 63 15 f7 c6 f2 e1 29 67 c7 24 34 22 14
Government of Macao, Macao Post Macao SAR ‎89 c3 2e 6b 52 4e 4d 65 38 8b 9e ce dc 63 71 34 ed 41 93 a3
Government of Mexico, Autoridad Certificadora Raiz de la Secretaria de Economia Mexico 34 d4 99 42 6f 9f c2 bb 27 b0 75 ba b6 82 aa e5 ef fc ba 74
Government of Portugal, Sistema de Certificação Electrónica do Estado (SCEE) / Electronic Certification System of the State Portugal ‎39 13 85 3e 45 c4 39 a2 da 71 8c df b6 f3 e0 33 e0 4f ee 71
Government of Serbia, PTT saobraćaja „Srbija” (Serbian Post) Serbia d6 bf 79 94 f4 2b e5 fa 29 da 0b d7 58 7b 59 1f 47 a4 4f 22
Government of Slovenia, Posta Slovenije (POSTArCA) Slovenia ‎b1 ea c3 e5 b8 24 76 e9 d5 0b 1e c6 7d 2c c1 1e 12 e0 b4 91
Government of Slovenia, Slovenian General Certification Authority (SIGEN-CA) Slovenia 3e 42 a1 87 06 bd 0c 9c cf 59 47 50 d2 e4 d6 ab 00 48 fd c4
Government of Slovenia, Slovenian Governmental Certification Authority (SIGOV-CA) Slovenia 7f b9 e2 c9 95 c9 7a 93 9f 9e 81 a0 7a ea 9b 4d 70 46 34 96
Government of Spain (CAV), Izenpe S.A. Spain 4a 3f 8d 6b dc 0e 1e cf cd 72 e3 77 de f2 d7 ff 92 c1 9b c7
Government of Spain (CAV), Izenpe S.A. Spain ‎30 77 9e 93 15 02 2e 94 85 6a 3f f8 bc f8 15 b0 82 f9 ae fd
Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV) Spain a0 73 e5 c5 bd 43 61 0d 86 4c 21 13 0a 85 58 57 cc 9c ea 46
Government of Spain, Dirección General de la Policía – Ministerio del Interior – España. Spain b3 8f ec ec 0b 14 8a a6 86 c3 d0 0f 01 ec c8 84 8e 80 85 eb
Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) Spain 43 f9 b1 10 d5 ba fd 48 22 52 31 b0 d0 08 2b 37 2f ef 9a 54
Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) Spain b8 65 13 0b ed ca 38 d2 7f 69 92 94 20 77 0b ed 86 ef bc 10
Government of Sweden, Inera AB (SITHS-Secure IT within Health care Service) Sweden 16 d8 66 35 af 13 41 cd 34 79 94 45 eb 60 3e 27 37 02 96 5d
Government of Switzerland, Bundesamt für Informatik und Telekommunikation (BIT) Switzerland ‎6b 81 44 6a 5c dd f4 74 a0 f8 00 ff be 69 fd 0d b6 28 75 16
Government of Switzerland, Bundesamt für Informatik und Telekommunikation (BIT) Switzerland ‎25 3f 77 5b 0e 77 97 ab 64 5f 15 91 55 97 c3 9e 26 36 31 d1
Government of Taiwan, Government Root Certification Authority (GRCA) Taiwan ROC f4 8b 11 bf de ab be 94 54 20 71 e6 41 de 6b be 88 2b 40 b9
Government of The Netherlands, PKIoverheid The Netherlands 10 1d fa 3f d5 0b cb bb 9b b5 60 0c 19 55 a4 1a f4 73 3a 04
Government of The Netherlands, PKIoverheid The Netherlands 59 af 82 79 91 86 c7 b4 75 07 cb cf 03 57 46 eb 04 dd b7 16
Government of the United States of America, Federal PKI USA 76 b7 60 96 dd 14 56 29 ac 75 85 d3 70 63 c1 bc 47 86 1c 8b
Government of the United States of America, Federal PKI USA cb 44 a0 97 85 7c 45 fa 18 7e d9 52 08 6c b9 84 1f 2d 51 b5
Government of the United States of America, Federal PKI USA ‎90 5f 94 2f d9 f2 8f 67 9b 37 81 80 fd 4f 84 63 47 f6 45 c1
Government of Tunisia, Agence National de Certification Electronique / National Digital Certification Agency (ANCE/NDCA) Tunisia 30 70 f8 83 3e 4a a6 80 3e 09 a6 46 ae 3f 7d 8a e1 fd 16 54
Government of Tunisia, Agence National de Certification Electronique / National Digital Certification Agency (ANCE/NDCA) Tunisia d9 04 08 0a 49 29 c8 38 e9 f1 85 ec f7 a2 2d ef 99 34 24 07
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) Turkey 1b 4b 39 61 26 27 6b 64 91 a2 68 6d d7 02 43 21 2d 1f 1d 96
Government of Uruguay, Correo Uruguayo Uruguay f9 dd 19 26 6b 20 43 f1 fe 4b 3d cb 01 90 af f1 1f 31 a6 9d
Government of Venezuela, Superintendencia de Servicios de Certificación Electrónica (SUSCERTE) Venezuela ‎dd 83 c5 19 d4 34 81 fa d4 c2 2c 03 d7 02 fe 9f 3b 22 f5 17
Government of Venezuela, Superintendencia de Servicios de Certificación Electrónica (SUSCERTE) Venezuela ‎39 8e be 9c 0f 46 c0 79 c3 c7 af e0 7a 2f dd 9f ae 5f 8a 5c

 

With a closer look we see that these 46 certificates are operated by 33 different agencies in 26 countries.

 

Wikipedia tells us there are 207 governments and now we know apparently 14% of them operate their own globally trusted root.

 

Though I love to travel and I consider myself a citizen of the world I have never needed to communicate with any of these governments using their private PKIs so I personally have marked them as “revoked” in CryptoAPI, I also manage which of the commercial root CAs I trust manually.

There are some other interesting observations we can gleam from the Root Program membership also, I will do more posts on these later.

Wanted: Senior Software Engineer (Back-End) [Manila]

Leave a reply

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 the Seattle area and another in Manila and need senior developers who are passionate about security and building technology for the modern web.

In this role you’ll write high-performance web services, core security subsystems, key management solutions, architect new solutions that make certificate and key management a breeze and interact with the open source community.

Most importantly, you’ll be a leader – writing groundbreaking code that continually changes and influences the industry.

 

Skills & Experience

  • Architecting, designing and implementing core services, processes and technologies that provide reliability, high availability, performance and scalability.
  • Extensive experience with database design and deployment.
  • Experience with applied cryptographic concepts such as certificates, certificate chains, and key management with a healthy interest in their XML and JSON counterparts.
  • Experience designing highly interactive web applications with performance, scalability, usability, and security in mind.
  • Experience developing software on Unix/Linux.
  • Love your version control (Git preferably).
  • 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.
  • 5 years of experience with database administration, support, optimizations and monitoring.
  • 5 years of design and development of extremely high volume, high availability applications and systems.
  • 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.

 

Keywords: Authentication, Authorization, Fraud, TCP/IP, load balancing, reverse-proxies, production web scaling, high-availability, high-volume web services, distributed systems and programming language design, Openssl, Bouncy Castle

Wanted: Senior Software Engineer / Lead [Manila]

Leave a reply

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]

Leave a reply

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]

Leave a reply

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.