by Shyam Mani
The session will discuss the following topics :
Introduction to DNSSEC
Why DNSSEC is needed
New RR records – DNSKEY, DS, NSEC and RRSIG
Relationship between the new RR records and keys aka Chain of Trust[demo]
Things to consider before you implement
Setup at Mozilla, before and after
Steps to switch
Possible issues to be aware of
Mistakes I made, and you shouldn't
Where we stand with DNSSEC today
Possible issues that delay DNSSEC implementation
Data from Mozilla (before and after DNSSEC)
Possible changes to Firefox/Other Software
by David Lazar, Michael Ernst and Werner M. Dietl
Are you tired of null pointer exceptions, unintended side effects, SQL injections, concurrency errors, mistaken equality tests, and other run-time errors that appear during testing or in the field? A pluggable type system can guarantee the absence of these errors, and many more real, important bugs.
Are you a software architect who wants to be able to quickly and easily implement custom checks that prevent more errors at compile time? You need a framework that supports you in creating a formally correct code checker.
This presentation is aimed at both audiences. A pluggable type system can give a compile-time guarantee of important properties. We will explain what it is, how to use it, and even how to create your own. You can create a simple pluggable type-checker in 2 minutes, and you can enhance it thereafter.
The demo uses the Checker Framework, which enables you to create pluggable type systems for Java. It takes advantage of features planned by Oracle for Java 8, but your code remains backward-compatible. The pluggable type-checker can be run as part of javac or via an Eclipse plug-in, and integration with build tools such as Ant and Maven is provided. The tools are "freely available":http://types.cs.washington.edu/checker-framework/.
The Checker Framework provides 12 pluggable type systems that are ready to use, including nullness, immutability, and locking checkers. The presentation will first develop a simple declarative type checker that checks the consistency of method signature strings. The presentation will then discuss the design and usage of more advanced checkers.
The Checker Framework has found hundreds of bugs in over 3 million lines of open source code, including from Oracle, Google, Apache, etc. Overall, we found that the type checkers were easy to write, easy for novices to productively use, and effective in finding real bugs and verifying program properties, even for widely tested and used open source projects. It is easy to improve the quality of your Java code, and you can start using the Checker Framework today!
Many applications have reacted to this by offering options to run all traffic through HTTPS. Examples include Gmail, Github, Facebook, and Twitter. Using HTTPS does go a long way in improving web application security. But in most cases HTTPS security is opt-in - probably due to difficulties in rolling out HTTPS on a large scale and added application complexity. This means that only relatively paranoid users benefit. Less fortunate users, like Ashton Kutcher, will often be "left vulnerable":http://techcrunch.com/2011/03/15/twitter-enables-always-use-https-setting/.
CSRF(cross-site request forgery) does not just force complexity though. Its existence actively stifles innovation. The new "cross-origin resource sharing specification":http://www.w3.org/TR/cors/, which allows servers to opt-into cross-origin XHR(XMLHttpRequest) requests, presents many possibilities for rich interaction between web applications. Unfortunately this specification is infrequently used because it opens up XHR(XMLHttpRequest) as another vector for CSRF(cross-site request forgery) attacks in cases where cookie authentication is used. In the eyes of many developers this is just too dangerous to justify exploring a new technology.
All of these problems are products of the fundamental design of cookie authentication: what is essentially a temporary password is transmitted with every web request and that password is easily accessed - directly by eavesdroppers or indirectly by third-party web pages.
21st–24th June 2011