Think about the following scenario:
Alice needs to upload a document with sensitive information to https://www.disk.net/. The Web server servicing this URL is run by Bob and uses TLS server and client authentication to ensure that Alice’s browser and Bob’s server can authenticate each other. Of course, both parties (client and server) need to have a certificate installed. In todays prevalent CA-based PKI, these certificates must be issued by CA’s that both entities trust. Bob’s server uses Alice’s client certificate for automatic login on Alice’s account.
Another server, run by Eve, is servicing https://www.disc.net/ and has been deliberately crafted to mimic the service at https://www.disk.net/ in order to fool people into uploading documents at the wrong service.
Eve’s server also has a certificate issued by a mutually trusted CA, and will similarly use Alice’s client certificate to do a login on a (perhaps dynamically created) account. So if Alice by mistake connects to Eve’s server instead of Bob’s server, it is likely that she will not notice her mistake.
Why doesn’t TLS in todays browsers prevent this scenario? Because
- todays web browsers by default accepts any server certificate issued by one of the root CA’s that they have been configured to trust. Todays browsers fully rely on CA’s to not issue certificates to servers that have been set up for phishing purposes. I doubt that todays CA’s live up to this responsibility.
- client certificates can in some cases actually assist Eve’s server in creating a login experience that makes Eve’s services more closely resemble those of Bob.
In other words, the problem is not in the TLS protocol or the implementation of it. Rather, the problem is in the PKI that underlies the integration of TLS in todays browsers.
I could find no obvious reason why my Windows 7 firewall was blocking internet access from my Windows Device Emulator to a server application running on the host PC. So, while the Windows CE application was running on the device emulator, trying to get connected with the server application on the host PC, I turned off the firewall, and as I expected, the Windows CE application could all of the sudden connect to the server.
What surprised me a bit, however, was that turning on the firewall again, let the Windows CE application continue to connect/disconnect to the server on the host PC. Now, after each reboot of the host PC, I always start up the device emulator, let the Windows CE application try to connect, start my server, and then turn off the firewall and then on again. It works every time.
I had a Windows 7 upgrade (from Home Premium to Ultimate) forced upon me; I was working with a Microsoft Device Emulator and needed to get a .NET Compact Framework application on the emulator to access the network on my Windows 7 host. That required installation of a Virtual PC network driver. Unfortunately, Virtual PC cannot be installed on Windows 7 Home Premium, so I had to upgrade.
To make things worse, an online upgrade is not available where I live. So I had to wait for the upgrade key to be shipped to me.
And when I got the key, things only got worse: I started up Windows Anytime Upgrade and entered the key as requested, and a text kindly informed me that the upgrade would take only 10 minutes. After 1.5 hours, the upgrade was still not done, and there was no network activity, as one could have expected.
I killed the Windows Anytime Upgrade processes and started over again. Same result. Tried to kill as many processes as possible and start over again. Same result. Did a logout and login and started the upgrade once more. Same result. Then decided to restart the machine, but that only made the machine hang during shutdown. After 15 minutes, I pulled the power cord and removed the battery. When I booted the laptop again, the boot manager correctly stated that Windows had not been closed down properly, but I chose to start Windows normally anyway. Windows 7 then started a cycle of 2 or 3 restarts/reconfigurations/updates after which it finally claimed it had upgraded to Windows 7 Ultimate and let me login again.
Needless to say; Windows 7 Ultimate isn’t exactly cheap, so I had expected a smooth upgrade. The experience I had was totally not acceptable!
I’ve recently had a deja-vu while reviewing a proprietary application level protocol; the protocol wasn’t robust with respect to loss of the connection at the transport layer. The reason for this was a design flaw I’ve seen before.
The proprietary protocol relied on a positive acknowledgement transport protocol (like TCP/IP) to ensure that unacknowledged packets got retransmitted. However, lost packets are typically not retransmitted indefinitely. TCP/IP protocol stacks, for example, only try to retransmit unacknowledged packets a limited number of times before aborting the connection.
So, if a connection breaks, how much data can a sender assume that the reciever actual got? Not much, actually. Lack of a positive acknowledgement of a packet could mean that the receiver never got the packet. However, it could also mean that the receiver actually got the packet, but the acknowledgement was somehow lost on its way back to the sender. A broken connection may therefore potentially leave the state of the two peers out-of-synch. When the transport layers become ready to exchange data again, the application layers must somehow be able to continue their protocol without knowing each others precise state.
The best strategy to cope with this problem depends on the problem domain/protocol. Retransmission of the last PDU may be one option, but it will require that the protocol can cope with duplicate PDU’s. Another solution (but often more involved) would be to have the application level protocol let peers probe each others state before continuing normal protocol flow.
Much the same conclusions can be drawn for negative acknowledgement protocols, by the way.
I’ve just released the first version of gnc2ods – an XSLT that converts a gnucash XML file to an OpenDocument 1.1 spreadsheet. See http://www.ohloh.net/p/gnc2ods for more information.
I’ve just released version 0.2.0 of tds2dbg. The new version is now able to insert debug information for public symbols as well as source code references (file and line number) in the dbg files. See http://www.ohloh.net/p/tds2dbg for more information.
Some time ago, I published tds2dbg – a small command line tool that converts Borland debug symbol files (*.tds) to Microsoft debug symbol files (*.dbg). See more on http://tds2dbg.sourceforge.net/
The tool was created while doing consultancy for one of my customers, but the customer was not too keen on maintaining it after I left. We therefore agreed to make it open source.
I’m about to get rid of my old ZyXEL router, so I decided to post my experiences and configurations before I forget all details.
I’ve had a ZyXEL P-2302HWL-P1 wireless router with VoIP support for a couple of years by now. I bought this router because it had the feature set I needed, and my ISP (Cybercity, now Telenor) had already provided me with a ZyXEL ADSL router (P-660R-D1) and I expected that one ZyXEL product would work smoothly with another ZyXEL product.
Sadly, getting VoIP to work against my telephony provide (Unotel) wasn’t all that easy. And in the process of getting it to work, I realized that the closed-source nature of the ZyNOS (ZyXEL OS) made it really difficult to understand what was going on. In comparison to what I’m used to with my Linux based devices, the level of logging provided by the P-2302 was insufficient, and there were few resources on the Internet where I could seek advice.
The best tools to analyze the VoIP problems actually turned out to be open source tools like Ekiga (started up with highest debugging level from a console) and a SIP command line tool (sipsak, I think – it’s a long time ago). So I pretty much gave up on the P-2302HWL and switched to getting Egika to work against Unotel. Once that worked, I had a good basis for getting the P-2302HWL to work against Unotel as well.
The ZyXEL configurations I succeeded with are as follows:
- DHCP enabled with a hard-coded IP address (10.0.0.3) for the ZyXEL P-2302HWL-P1 on the LAN.
- NAT set to full feature with the following address mappings:
- Type 1-1: Local Start IP 10.0.0.3, Local End IP N/A, Global Start IP 0.0.0.0, Global End IP N/A, Server Mapping Set N/A
- Type Server: Local Start IP N/A, Local End IP N/A, Global Start IP 0.0.0.0, Global End IP N/A, Server Mapping Set 2 (Consisting of a default server 10.0.0.3 and no other entries).
Essentially, the above disables any firewall-like behaviour of the ZyXEL P-660R-D1.
- WAN IP Address Asignment: Get automatically from ISP
- Firewall enabled
- SIP Account:
- Number: your Unotel user name (UNOxxxxx)
- SIP Local Port: 5004
- SIP Server Address: sip1.unotel.dk
- SIP Server Port: 5060
- REGISTER Server Address: sip1.unotel.dk
- REGISTER Server Port: 5060
- SIP Service Domain: sip.unotel.dk
- User name: your Unotel user name (UNOxxxxx)
- Password: your Unotel password
- URL Type: SIP
- Expiration duration: 3600
- Register Re-send timer: 100
- Session expires: 300
- Min-SE: 180
- RTP start port: 15000
- RTP end port: 20000
- Primary Compression Type: G.711A
- Seconday Compression Type: G.729
- Third Compression Type: G.711u
- STUN server: stun.ekiga.net
- STUN port: 3478
- Use NAT: No
- Outbound proxy: None
- NAT Keep Alive: Inactive
- MWI: Disabled
- Fax Option: G.711Fax Passthrough
- Caller Ringing: Disabled
- On Hold: Enable
In summary, I’d say that I’m a little disappointed by the ZyXEL devices:
- Investigation of problems is difficult due to insufficient logging.
- Difficult to find answers to problems on the Internet – would have been easier if the router was based on open source software.
- Wired and Wireless links unstable. I often lost my connection – both from Linux and Windows based devices. Reconnecting often helped
- The product is unstable. Sometimes, after loosing my internet connection, I had to restart the P-2302HWL to get connected again.
- I couldn’t get Windows Vista to connect wirelessly at all (although, after upgrading to a LinkSys WRT610N, I have realized that this could have been due to me getting confused by a way too complex interface to network management on the Vista partition of my Lenovo laptop – one of the places where KDE/Linux is far easier to work with)
- VoIP quality at the other end is poor. When listening in the B&O Beocom 4 attached to the P-2302HWL, the quality was good, but persons at the other end of the connection often complained about echos and poor sound quality. Could be a problem with Unotel.
- People trying to call me often complain that they were unable to get through. Could be a problem with Unotel. Also, I’ve never been able to reproduce this myself.
- When powering up the two ZyXEL devices concurrently, the P-2302HWL most often failed to perform a SIP registration with Unotel. Restarting the P-2302HWL always fixed the problem. Seems like a timing issue as the P-2302HWL now fails consistently (at power up – restart of the P-2302HWL still solves the problem) after I’ve inserted my new Linksys router between the two ZyXEL devices. As I had a workaround (restart of the P-2302HWL), I never got around to analyzing the traffic between the two ZyXEL devices to understand the problem further.
- Failed to get DTMF tones and “Show caller number” to work.
The above exemplifies a conclusion that I’ve drawn from similar experiences: Products based on proprietary closed-source software are more likely to disappoint their customers because: 1) It is really difficult to provide a sufficient level of user friendliness to allow for smooth installation, configuration, and problem analysis, and 2) such products tend to have small or non-existing communities of users that can help and guide each other.