Pocket DnDns Release 1

11:31 PM j. montgomery 0 Comments

I was asked if the DnDns .NET Resolver library I've put together works with the WinCE/PocketPC/Windows Mobile platforms. At the time, I wasn't sure, but I was pretty sure it might. I recently had some free time and I decided to give it a shot. After about 20 minutes I had a version ready with a test GUI. There were some very minor changes needed to port it.

I've release the source as well as a cab file for the WinCE platforms that installs a simple GUI that allows you to test the DnDns library.



Get Pocket DnDns Release 1 here.

As always, please post any issues or requests at the CodePlex site. I also enjoy hearing about where my libraries end up being used so if you feel so inclined, let me know.
kick it on DotNetKicks.com

0 comments:

DnDns - Updated!

10:38 PM j. montgomery 3 Comments

I've finally got around to patching a few bugs in DnDns. I've not posted a new Release yet, so you'll need to get latest and re-build. There was a pretty major bug in the DNS Lable decompression method that I've fixed so you'll want to make sure you get at least changeset #18865 from Codeplex.
The following issues have been fixed:

  1. Bug decompressing DNS Labels when resolving any DNS name. This only tends to pop up more when there were a lot of query results for a query. It turns out I was truncating six of the most significant bits of the byte pointer offset when unpacking the DNS labels.

  2. A few cast errors in the SrvRecord class had the Port and a couple other properties always returning zero.

  3. Finally, I added a UDP Socket timeout so that the socket wouldn't wait forever before timing out if the server wasn't responsive.


Thanks to those who were nice enough to post the issues on the CodePlex site. Changeset 18865 contains all of the above fixes.

3 comments:

Professional K2 [blackpearl]

9:40 PM j. montgomery 0 Comments


It's time for a shameless plug...

The end of another project draws near for me. We're finishing up Professional K2 [blackpearl] and it should be out sometime in fall or early winter. The book is now available for pre-order on Amazon and other sites - yes, that's my mug on the far left end. This book isn't only for developers, but also for business users - so if you use K2 blackpearl, or want to use K2 blackpearl, check it out.

If you aren't familar with K2 and you use Windows SharePoint Services (WSS 2.0 or 3.0) or Microsoft Office SharePoint Server (MOSS), Workflow Foundation (WWF), ASP.NET or just plain .NET applications and find yourself struggling to maintain applications that have any variety of workflow/BPM in it - check out K2, it's a pretty awesome product that will make your life about 20 times easier. If you're not familar with K2, the book will give a great introduction and some in-depth coverage as well.

If you need assistance with K2 - call my company, ATGi - we're also K2 Partner's.

0 comments:

DnSmtp – A .NET SMTP Client Library

11:19 AM j. montgomery 0 Comments

Related to my recently released DNS Client library, DnDns, I’ve finally gotten around to releasing a SMTP client library.
This SMTP library provides basic SMTP functionality – it’s able to deliver emails with multiple text mime parts and a few different types of attachments – adding additional attachment types via code should be trivial.
The one main benefit DnSmtp provides over the native .NET Mail implementation is the ability to deliver mail messages directly to the recipient’s email server. It does this by doing an MX lookup (using DnDns) on the email recipient’s domain name and then connects directly to that server to deliver the message. This, in some cases, can provide additional verification of whether an email was successfully delivered to the destination.  This doesn’t work in all cases though -some email systems, like qmail, accept all email messages and then bounce them back if the account doesn’t exist locally.
One area where it falls short from the .NET 2.0 implementation is the ability to encrypt emails.  This is a feature I’d like to eventually add, time permitting.
This SMTP library was originally conceived back in 2001 when we needed to send email from one of our web servers – and we discovered we needed to install Outlook in order to get the .NET 1.1. email functions to work properly, apparently MS decided to have code dependencies that weren’t included in the OS – they have since fixed this in .NET 2.0.  I had some spare time so I started putting this library together. It’s gone through a couple iterations since them, but it’s mostly the same at its core. Since this library is around 8 years old, it’s a bit rough around the edges and looking at it again, I can see many areas for improvement as well as new important features to add.
For now, I have released it as is on CodePlex under the New BSD license. As time permits, I hope make some enhancements to it.
If you happen to use DnSmtp, please report any bugs and/or feature enhancements to the DnSmtp CodePlex site. You can download the source or binary dll here:
DnSmtp – A .NET SMTP Client Library
You’ll also need the DnDns library - DnSmtp is dependent on it.

0 comments:

DNS-O-MATIC Sync Service - .NET Windows Service

10:10 PM j. montgomery 3 Comments

I have been a fan of OpenDNS for a while - it is an excellent free service that will bring an additional layer of security to home and small/medium business networks at the DNS level by providing content filtering, phishing protection, domain blocking, adult site blocking, web proxy blocking, domain white-listing, and typo correction. They also claim to reduce the possibility of cache poisoning and pharming "due to its unique handling of DNS requests and multiple levels of validation applied to all DNS queries."1
Additional features (non-security related) include domain shortcuts and a very LARGE cache for speedy name resolution
The only trick (if you want to call it that) to receiving the all the features of OpenDNS is that they need to know your current public IP so it can be associated with your specific OpenDNS settings - this is simple if you have static public IP, but if you are assigned a dynamic IP you have to have a mechanism to notify OpenDNS of your current latest and greatest public IP. This is important whether at home or if you're out and about with your laptop on other public networks where the DNS servers may have been poisoned/hijacked/pharmed.
Because of the need to keep track of your changing public IP, OpenDNS created a service called DNS-O-Matic. DNS-O-Matic's purpose is to allow routers and software clients to notify them of your current public IP and they, in turn, will notify OpenDNS so your settings can follow you. However, DNS-O-Matic didn't just stop there, they also support notifying a myriad of other services that your IP has changed as well - services such as DynDNS, NO-IP.com, and of course OpenDNS. I think last I counted around 29 different services they will update for you.
I briefly looked at the API documentation for DNS-O-Matic and it really couldn't be any easier - it's a basic HTTP GET request with some URL parameters. With this information in hand, I decided to take a few hours on a weekend and bang out a Windows Service in .NET. It doesn't support all of the features of DNS-O-Matic (i.e. Dns-O-Matic will update MX records and other types of things the other services support), but this service supports the core one - updating your changing IP.
I took a few snippets of code I have found on various sites on the Internet and others techniques I have come up with and brought them together in this service. If you've never written a windows service, this would be a great project to take a look at as a primer. Things such as:
  1. Setting up a Windows Service Recovery Options programmatically and other Windows Service tricks in .NET - props to Neil Baliga's project titled "A ServiceInstaller Extension That Enables Recovery and Autostart Configuration" on codeproject.com.
  2. Changing a Windows Service DACL's to limit users' ability on the local system to stop/restart a service (via p/invoke - thanks to pinvoke.net)
  3. Using the System.Threading.Timer in coordination with the System.Diagnostics.StopWatch classes.
  4. Using the System.Threading.AutoReset class.
At least one of these I plan on blogging about in more detail at a later date.
Anyway - enough of the chatty-ness...I've listed the project as OpenSource on CodePlex under the New FreeBSD License:
DNS-O-Matic Sync Service for Windows

3 comments:

ASP.NET 2.0 SmartCard HttpModule + Role/Membership

8:27 PM j. montgomery 5 Comments

UPDATE: An updated version is out. Read more about it here.

http://securitythroughabsurdity.com/2010/05/smart-card-authentication-module-update.html
This week I finally have had some time to take a look underneath the Membership and Roles infrastructure in ASP.NET 2.0 and have a significant update to the ASP.NET SmartCard HttpModule coming in the next couple weeks, as well as some necessary additions.
A preview of this update:
  1. SmartCard support under the System.Web.Security.Membership class
  2. SmartCard support under the System.Web.Security.Roles class
  3. Support for the SqlRoleProvider (with the SmartCardSqlRoleProvider)
  4. How to provide auto-enrollment and manual enrollment of Smart Card users into your application.
I'll also provide some behind the scences with the RolePrincipal Class and how it works with the SmartCardIdentity and SmartCardPrincipal classes...
Stay tuned!

5 comments:

DnDns - A .NET DNS Client Library (Resolver)

1:08 PM j. montgomery 19 Comments

UPDATE: Also see this post on DnDns update.
I've been sitting on the source code for a DNS resolver library I wrote for a few years now, wondering what to do with it - and too busy to really think much about it anyway. Finally I've decided to release it on CodePlex under the new BSD License for others to learn from and use.
It was originally done using .NET 1.1 - I've ported it to .NET 2.0 - though there is no real differences between the two versions. It is a fully managed implementation written in C# - I suspect it will run just fine on Mono since there's no specific MS Windows namespaces required...but I haven't had time to try it out yet - if anyone has a chance to try it out, let me know how it goes.
The project on CodePlex is located here:
DnDns - A .NET DNS Client Library
Doing a standard 'nslookup' on www.google.com would be done like this in code:
To do a normal Host (A) lookup:
1 DnsQueryRequest request = new DnsQueryRequest();2 DnsQueryResponse response =
3 request.Resolve(dnsServer, "www.google.com",4 NsType.A, NsClass.INET, ProtocolType.Udp);
To lookup Google's gMail MX record for email:

1 DnsQueryRequest request = new DnsQueryRequest();2 DnsQueryResponse response =
3 request.Resolve(dnsServer, "gmail.com"
4 NsType.MX, NsClass.INET, ProtocolType.Udp);
To get the answer, loop over the response.Answers[] array...you can also inspect all aspects of the DNS record response (headers, answers, additional records, etc.).
Motivation
I enjoy implementing protocols. My first network protocol I implemented was a Quake 2 server browser in Java - you could find Quake servers on the Internet and also check out the score of a game that was in-process from a particular server (very similar to early versions of GameSpy Arcade). After that I was hooked - leaning the internals of how the Internet functions is fascinating to me.
I went on to implement a FTP client, a native SMTP mailer (the main reason being that .NET 1.1 required Outlook/CDONTS installed to handle SMTP which was overkill of a requirement), a Syslog listener for keeping tabs on my Firewalls, FreeBSD Servers, and routers - which I'm also working to release soon as a part of another project I'm working on (stay tuned), and the protocol of this discussion, DNS.
In retrospect, the DNS client was probably the most interesting protocol to implement. It's clear the goal in the DNS protocol was to be very light weight and to utilize very little bandwidth. I enjoyed seeing how these efficiencies were implemented in the protocol back when a bandwidth was not as available as it is today.
It's not simply because they choose originally to use datagrams (UDP) that makes the DNS protocol light weight - though that's part if it - it's how the data is packaged for transmission. If that sort of thing interests you, check out section 4.1.4 titled "Message Compression" in RFC 1035. It is an incredibly simplistic type of compression...to reduce repetition of domain names in the message, they stored pointers throughout the message that point to previous occurrence of the same name so names are never duplicated within a message. It's surprising how little space this seems to save, but I suspect every little bit of savings were important back when the system was originally created.
Below is a list of the RFC's I used to implement the DNS client library (as well as Ethereal which was indispensable of course):
I may be missing a couple - it's been a while since I've reviewed the RFC's for which NSTYPE is in which RFC...of course there are some new features in DNS I'm interested in adding, specifically the DNSSEC record types.
Again, here's the link to the DnDns project on CodePlex:
DnDns - A .NET DNS Client Library
Samples are provided on the CodePlex site. Feedback, problems, and suggestions are welcome.

19 comments:

The "White Screen" Bug in IE with ASP.NET

3:06 PM j. montgomery 5 Comments

Recently I ran across a pretty odd issue on an ASP.NET web site that I was able to work through. 

Setup
1. Internet Explorer
2. Smart Card Authentication with SSL/TLS
3. ASP.NET 2.0 web site running on IIS 6.0 on Win2k3

Symptoms
When using the web site, users complained that at certain points when using the site, they would click on something and the page in IE would go 'white' - the page would look exactly like the 'about:blank' page. While not necessarily a very technical name, it was certainly descriptive of what was happening.

After trouble-shooting further it was determined that the page only went white after the user left the web browser sit for a couple minutes. Then when the user did a POST, the page went blank.

At this point the cause was speculated to be anything from a piece of networking equipment (a proxy?) between IE and web server, to the web server itself, to the .NET web application (depending on who you asked).

Troubleshooting
My first goal was to duplicate the problem on my system and I was able to reproduce it as described in MOST cases, but not 100% of the time.

Next, on the blank page, I did a "View Source", turns out it had  the entire contents of the previous page before the POST occurred.

Out of habit I saved the HTML source and check it's file size...the page was over 1MB.  Turns out the developer isn't managing ViewState properly with a GridView.  My initial thought is that this is worth pursuing as the root cause.  I did the same test on a page with a small ViewState and the error did not occur.

So at this point, I think I know what the solution is, but I don't know what the actual problem really is, so there's more work to do.

Next I pull out Fiddler, a HTTP debugging proxy - even though the ViewState is large, IE should still be able to render the page so I want a lower level look at what's going on. There's also this strange timing issue where the bug only occurs after two minutes. After firing up Fiddler, loading the first page then waiting two minutes before POSTing more data, the following HTTP error is reported in the Fiddler output.

HTTP/1.1 413 Request Entity Too Large

This error message didn't immediately reveal what the issue was - only after some extensive searching that combined the "HTTP 413 Request Entity Too Large" error combined with search terms related to Client Certificates did the appropriate Microsoft Article actually come up.

The REAL Issue
This issue is a problem in the underlying protocol (SSL/TLS) authentication specification; this is not a Microsoft or an IIS problem nor is it necessarily a developer problem as long as care is taken to keep certain “features” of ASP.NET in check. This problem will show up on any web site that attempts to do an HTTP POST with a large amount of data to an IIS web server while at the same time, re-establishing the SSL/TLS encrypted channel (HTTP CONNECT). This is why this particular problem is seen only after allowing a period to pass.

This problem is typically seen when uploading files to a web server and rarely seen when submitting a HTTP POST of Form variables, because rarely do they need to be larger then a few kilobytes.

According to Microsoft Technet article on this issue:

“If client renegotiation is requested, the request entity body must be preloaded using SSL preload. SSL preload will use the value of the UploadReadAheadSize metabase property, which is used for ISAPI extensions. However, if UploadReadAheadSize is smaller than the content length, an HTTP 413 error is returned, and the connection is closed to prevent deadlock. (Deadlock occurs because a client is waiting to complete sending a request entity, while the server is waiting for renegotiation to complete, but renegotiation requires that the client to be able to send data, which it cannot do).” [1]

To summarize, the UploadReadAheadSize metabase property in IIS 6.0 needs to be large enough to load the SSL POST entity body such that on Client Certificate (CAC) renegotiation, a deadlock does not occur.

It would be unwise to increase blindly the UploadReadAheadSize metabase property without consideration of the consequences (it has a max value of 4GB). If the size is set too large it becomes an attack vector for Denial of Service attacks (DoS) since we might exhaust resources on the system.

The default size for UploadReadAheadSize metabase property in IIS 6.0 is 49,152 bytes.

The Solution
The solution to the problem is not necessarily to just increase the UploadReadAheadSize site limit as you will always be able to create a page on a web site that will cause this problem unless you increase the POST size so large as to create a security issue that creates the DoS situation. The best way to remediate this problem is to reduce data POST sizes when possible instead of playing a guessing game with the UploadReadAheadSize metabase property.

With this in mind, Developers must familiarize themselves with ASP.NET best practices as they apply to ViewState size especially in any DoD environment which requires Client Certificates (CAC / Smart Cards) for authentication making a non-issue, an issue. Dino Esposito, an authority on ASP.NET development, has some information on the topic of recommended ViewState sizes here: ASP.NET 2.0: ViewState Numbers. He recommends ViewState not exceed 7KB. My personal view is that his number, in some cases, might be a bit conservative. I take the stance that the ViewState size should not exceed the size of what the industry has deemed acceptable optimized image size that can reasonably be displayed on a web site. This number is often greater then 7KB as rarely is it an issue to download an image of even 10 KB to 20 KB, but that’s on the very high end and is probably a bit excessive for ViewState especially if your web site is already graphics intensive.

Now the fact that Internet Explorer just displayed a blank page when encountering a 413, I think could be classified as a bug. Reporting the "HTTP 413 Request Entity Too Large" error back up to the user seems appropriate.


References

[1] - Client cannot renegotiate request and returns an HTTP 413 error (IIS 6.0)

  NOTE: This KB article seems to have a mistake:
  cscript adsutil.vbs set w3svc/1/uploadreadaheadsize 200

  Should read:
  cscript adsutil.vbs set w3svc/1/uploadreadaheadsize 204800

According to the IIS documentation, the argument is in bytes - not in kilobytes. See UploadReadAheadSize Metabase Property in the Microsoft IIS 6.0 Reference.

5 comments: