On this page

DEP is useless?
MD5-signed X.509 certificates in trouble
Tired of all the UAC prompts?
WSE: Another Compression Filters Update!
WS-Addressing makes its way to W3C
WSE: Compression, Security and Performance
WSE, Secure Conversation and Performance
WSE and the Next Generation of Security
Developer Lifestyles



The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

RSS 2.0 | Atom 1.0 | CDF

Send mail to the author(s) E-mail

Total Posts: 83
This Year: 0
This Month: 0
This Week: 0
Comments: 5

Sign In

# Thursday, January 15, 2009
DEP is useless?
Thursday, January 15, 2009 6:35:06 PM UTC ( Security )

Interesting point by Magnus Akselvoll.

Perhaps two of the most malware-facing application are the ones that don’t quite work. Enough said.

Comments [0] | | # 
# Wednesday, December 31, 2008
MD5-signed X.509 certificates in trouble
Wednesday, December 31, 2008 10:25:26 AM UTC ( Security )

Security researchers have proven a successful collision attack against MD5-signed X.509 certificates. This would enable an attacker to create their own X.509 certificate with same digital signature as the original certificate. This certificate can then be used to sign additional certificates and provide whatever details they please, all trusted by existing security infrastructures. This will work great phishing and man-in-the-middle attacks.

This was performed using a cluster of 200 PlayStation 3’s and is reproducible with a couple of days of computing.

The risks inherent when using the MD5 hash algorithm have been known for quite some time and the recommendation is to move to the SHA family. Most certificates should as such be signed with SHA-1 instead of MD5, but history has proven that there are always old installations and old configurations around.

The following public Certificate Authorities are still using MD5 signing:

    • RapidSSL
    • FreeSSL
    • TrustCenter
    • RSA Data Security
    • Thawte

The security researchers sampled 30.000 certificates, whereof 9.000 were using MD5 and 97% of those were issued by RapidSSL.

It’s time to review the algorithm used on your certificates; hopefully it is using SHA. This is easily verifiable if you look at the certificate properties. This is not a problem with EV certificates as they do not support the MD5 algorithm.

Microsoft recently issued this security advisory.

Comments [0] | | # 
# Sunday, October 12, 2008
Tired of all the UAC prompts?
Sunday, October 12, 2008 10:23:59 AM UTC ( Security | Tools )

Norton Labs have created a utility that removes a lot the UAC annoyances you may be experiencing in Windows Vista. It allows you to configure a list of applications that can be launched in admin mode without incurring a UAC prompt, basically a “do not ask me again” dialog. Great for everyday applications like Visual Studio.

May be a better solution than disabling it completely ;)

There is one caveat though, it will send information to Norton whenever you get a prompt. It will send the filename and hash of the files involved, as well as your response. The intention is to create a white list that will be shipped with the finished product.

There is a free beta version and a FAQ available at Norton Labs, both X86 and X64 editions.

Comments [1] | | # 
# Thursday, September 16, 2004
WSE: Another Compression Filters Update!
Thursday, September 16, 2004 7:55:39 PM UTC ( Security | Tools | WSE )

It is great to see that someone has a taken an interest in the WSE compression filters I’ve been working on. Rodolfo Finochietti has added several new features to the code base.

  • Compress attachments
  • More algorithms (Deflate, Zip)
  • Compression level (set through compression context)
  • Threshold. Compresses according to the minimum message size (body size plus all attachments size)
  • Several other improvements and code cleaning.

    This is really exciting news. Great work Rodolfo!

    You find a list of download links here, or you can download it directly from this link.

  • Comments [0] | | # 
    # Tuesday, August 10, 2004
    WS-Addressing makes its way to W3C
    Tuesday, August 10, 2004 8:23:12 PM UTC ( Architecture | Indigo | Security | WSE )

    WS-Addressing, a vital piece of XML Web Services infrastructure, has just been submitted to the W3C.

    With WS-Security being an official OASIS standard, and WS-Addressing entering the W3C standardization process, we may soon be looking at the first stable set of advanced web services infrastructure.

    These two specifications form the foundation of the Microsoft Web Services Enhancements toolkit's functionality. Perhaps we will soon say goodbye to backwards incompatibility and short support lifecycles in this particular area.

    As always, it is great fun to follow the advances.

    Comments [0] | | # 
    # Sunday, February 15, 2004
    WSE: Compression, Security and Performance
    Sunday, February 15, 2004 8:16:33 PM UTC ( Security | WSE )

    We have been doing a lot of WSE testing at work while developing our new integration infrastructure. As a part of this project we have built a filter for message level compression in WSE.

    One of the interesting things we found out while performance testing the solution was the speed increase resulting from message compression. The system we are building transfers sensitive data across the internet and we are using X509 certificates for integrity and confidentiality. Naturally, we had to apply the compression before the security mechanisms were invoked, as compressing encrypted data isn’t efficient at all. However compressing xml data is very efficient; often resulting in 80% smaller message bodies.

    Having a smaller message body means that the encryption and signing process has a lot less data to deal with, and this reduced the processing time significantly. We did of course consider that the smaller payload would increase transfer performance, but on our test-setup this was not a issue.

    The bottom line is that our initial testing shows that the gzip compression algorithm is faster than the encryption and signing process used by WSE. This came as a surprise to us as signing involves hashing and the encryption implementation uses a block cipher, and neither of these should have performance issues with large amounts of data; at least not compared to a compression algorithm!

    This topic requires a bit more research before I can reach a conclusion, but so far I am a bit surprised. On the other hand, the results we are seeing could be related to some other part of the process like the normalization algorithm.

    Having fun ;)

    Comments [0] | | # 
    # Tuesday, January 13, 2004
    WSE, Secure Conversation and Performance
    Tuesday, January 13, 2004 3:04:42 PM UTC ( Security | WSE )

    I read and hear that increased performance is one of the primary reasons for employing secure conversation instead of PKI and X509 certificates. Usually these statements are based upon the fact that PKI encryption is relatively slow. This becomes a problem when large amounts of data are involved because the encryption algorithm used with X509 certificates is not a block cipher.

    I am not going to give an exhaustive explanation of how block ciphers work, but just note that they scale very well as it’s usually just the first block that is encrypted and then a chaining algorithm is applied to transform the next blocks based on the encrypted output of the first block. The asymmetric algorithm used by X509 certificates splits the data up into chunks of the maximum allowed size and then encrypts each one of them before chaining the encrypted blocks together. Moving back to the topic at hand I would like to shed some light on the statement about performance and secure conversation.

    If you use an X509 certificate to encrypt a message using WSE a symmetric key is generated. This symmetric key is then used to encrypt the specified parts of the message. Finally, it is this session key that is encrypted with the X509 certificate. This means that the asymmetric PKI encryption is only used to encrypt a small key, and never the entire document. As a result, the scalability of the asymmetric PKI encryption isn’t really a big performance issue when used in this way.

    There is an overhead involved in generating and encrypting a new symmetric key for each message, but how this affects the overall performance of your system depends upon your architecture and distribution. I would think it would be a non-issue for most internet-based applications.

    There is of course also an overhead involved when initiating a secure conversation as trust must be validated and the session key must be generated and distributed. As a result, the amount of messages exchanged within each conversation becomes an important factor when deciding on the performance impact.

    If you don’t need client authentication you may also use the secure conversation session key to ensure integrity, and that will shave some cycles off using X509 certificates for digital signatures.

    There are in other words performance concerns when using either one of these security strategies, and which one is the fastest depends upon your architecture and usage patterns.

    Comments [0] | | # 
    # Wednesday, December 31, 2003
    WSE and the Next Generation of Security
    Wednesday, December 31, 2003 1:38:20 AM UTC ( Security | WSE )

    I have spent a lot time with WSE 2.0 in the last few weeks, and as both my code and my mindset moves from testing and research to building production quality systems, I am beginning to think about how hard it is to get the security choices right with WSE 2.0.

    From a practical point of view, the move from plain ASP.NET Web Services to WSE and WS-Security is about moving from the SSL checkbox in IIS to a fairly imperative and challenging programming model in WSE 2.0. While the SSL-checkbox is inflexible and does not provide you with a lot of room for configuration, it is reasonably simple to get right. The WSE toolkit on the other hand provides you with a lot of room for mistakes and bad decisions. Throw a bit of WS-SecureConversation and WS-Trust into the mix and things really start to get interesting.

    Even though WSE is an advanced toolkit for early adopters, it is still being marketed and generally perceived as the technology that will ensure secure web services. In the real world, it needs to be easy to build secure services. This is not because security is a simple concept to grasp, as it in fact is hugely complex, but because it is a basic requirement in any software project. We need to be practical and provide solutions that by default are as close to bulletproof as we can get them.

    Looking at the samples in the WSE 2.0 TP distribution, I fail to find one that ensures integrity and confidentially for both the request and the response in a message exchange, but I have not done an exhaustive search. Given the affection that exists for copy and paste development, I am scared of what will travel from and to web services in the next couple of years.

    I know that making the move to WSE is about a lot more than just migrating from SSL/ TLS to the WS-x family, but I think that it will be one of the most common scenarios.

    My current thinking is that I would not recommend using WSE unless you have a very strong understanding of security and you have a dire need for the functionality it provides.

    This entry seems a bit negative towards WSE, but I assure you that it is a great toolkit with a lot of good stuff in it. My concern is with whether or not the migration from SSL checkbox security to WSE-security is an evolution that will increase security or be a great source for error and confusion. Simple end-to-end samples together with practical prescriptive guidance may be a viable path towards solving this problem.

    I am just in the beginning of forming my opinions on this topic; perhaps they will change.

    Comments [0] | | # 
    # Friday, December 27, 2002
    Developer Lifestyles
    Friday, December 27, 2002 6:21:48 PM UTC ( Security )

    Keith Brown (Mr. Windows Security) has written an interesting piece about developer lifestyles in relation to security. Definitely worth a read!

    Comments [0] | | #