On Version Control Systems

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/on-version-control-systems.html

Here’s what I have to say about today’s state of version control systems in Free Software:

We shouldn’t forget that a VC system is just a development tool. Preferring
one over the other is nothing that has any direct influence on code quality, it
doesn’t make your algorithms perform any better, or your applications look
prettier. It’s just a tool. As such it should just do its job and get out of the
way. A programmer should have religious arguments about code quality, about
algorithms or about UIs, but what he certainly should not have is religious
arguments over the feature set of specific VCSes[1].

Does this mean it doesn’t matter at all which VCS to choose? No, of course
it does matter a lot. The step from traditional VCSes to DVCS is a major one, an
important one. Starting a fresh new Free Software project today and choosing
CVS or SVN is anachronistic at best.

Which leaves of course the question, which DVCS to pick. If you take the
“get out of the way” requirement seriously than there can only be one answer to
the question: GIT. Why? It certainly (still) has a steep learning curve, and a
steeper one than most other VC systems. But what is even harder to learn than
GIT is learning all of GIT, Mercurial, Monotone, Bizarre^H^H^H^H^H^H^HBazaar,
Darcs, Arch, SVK at the same time. If every project picked a different VCS
system, and you’d want to contribute to more than just a single project, then
you’d have to learn them all. And learning them all means learning them all not
very well. And needing to learn them all means scaring people away who don’t
want to learn yet another VCS just to check out your code. Fragmentation in use of VCSes for Free Software projects hinders development.

Which brings me to the main point I want to raise with this blog story:

It is much more important to make contributing to Free Software projects
easy by choosing a VCS everyone knows well — than it is to make it easy by
choosing a VCS that everyone could learn easily.

So, and which VCS is it that has a chance of qualifying as “everyone knows
well” and is a DVCS? I would say there is only one answer to the question: GIT.
Sure, there are some high-profile projects using HG (Mozilla, Java, Solaris),
but my impression is that the vast majority of projects that are central to
free desktops do use GIT.

Certainly, some DVCSes might be nicer than others, there might be areas
where GIT is lacking in comparison to others, but those differences are tiny.
What matters more is not scaring contributors away by making it hard for them
to contribute by requiring them to learn yet another VCS.

Yes, with CVS, SVN and GIT I think I have learned enough VC systems for now.
My hunger for learning further ones is exactly zero. Let me just code, and
don’t make it hard for me by asking me to learn your favourite one, please.

Or in other, frank words, if you start a new Open Source project today, and you
don’t choose GIT as VCS then you basically ask potential
contributors to go away.

ALSA recently switched from Mercurial to GIT. That was a good move.

So, please stop discussing which DVCS is the best one. It doesn’t matter. Picking one
that everyone knows is far more important.

That’s all I have to say.

Footnotes

[1] Of course, unless he himself develops a VC system.

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/06/20/voip-encryption-easy.html

Ian Sullivan showed me
an article
that he read about eavesdropping on Internet telephony calls. I’m baffled at
the obsession about this issue on two fronts. First, I am amazed that
people want to hand their phone calls over to yet another proprietary
vendor (aka Skype) using unpublished, undocumented non-standard
protocols and who respects your privacy even less than the traditional
PSTN vendors. Second, I don’t understand why cryptography experts
believe we need to develop complicated new technology to solve this
problem in the medium term.

At SFLC, I set up the telephony system as VoIP with encryption on
every possible leg. While SFLC sometimes uses Skype, I don’t, of course, because it is (a)
proprietary software and (b) based on an undocumented protocol, (c)
controlled by a company that has less respect for users’ privacy than
the PSTN companies themselves. Indeed, security was actually last on
our list for reasons to reject Skype, because we already had a simple
solution for encrypting our telephony traffic: All calls are made
through a VPN.

Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the
home office. From there, they have access to register a SIP client to
an internal Asterisk server living inside the VPN network.
Using that SIP phone, they could call any SFLC employee, fully encrypted. That call
continues either on the internal secured network, or back out over the
same VPN to the other SIP client. Users can also dial out from there to any
PSTN DID.

Of course, when calling the PSTN, the encryption ends at SFLC’s office, but that’s the PSTN’s fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However,
with minimal effort, and using existing encryption subsystems, we have
end-to-end encryption for all employee-to-employee calls.

And it could go even further with a day’s effort of work! I have a
pretty simple idea on how to have an encrypted call to anyone
who happens to have a SIP client and an OpenVPN client. My plan is to
make a public OpenVPN server that accepts connection from any
host at all, that would then allow encrypted “phone the
office” calls to any SFLC phone with any SIP client anywhere on
the Internet. In this way, anyone wishing end-to-end phone encryption
to the SFLC need only connect to that publicly accessible OpenVPN and
dial our extensions with their SIP client over that line. This solution
even has the added bonus that it avoids the common firewall and NAT
related SIP problems, since all traffic gets tunneled through the
OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol)
works, SIP automatically does!

The main criticism of this technique regards the silliness of two
employees at a conference in San Francisco bouncing all the way through
our NYC offices just to make a call to each other. While the Bandwidth
Wasting Police might show up at my door someday, I don’t actually find
this to be a serious problem. The last mile is always the problem in
Internet telephony, so a call that goes mostly across a single set of
last mile infrastructure in a particular municipality is no worse nor
better than one that takes a long haul round trip. Very occasionally,
there is a half second of delay when you have a few VPN-based users on a
conference call together, but that has a nice social side effect of
stopping people from trying to interrupt each other.

Finally, the article linked above talks about the issue of variable bit
rate compression changing packet size such that even encrypted packets
yield possible speech information, since some sounds need larger packets
than others. This problem is solved simply for us with two systems: (a)
we
use µ-law,
a very old, constant bit rate codec, and (b) a tiny bit of entropy
is added to our packets by default, because the encryption is occurring
for all traffic across the VPN connection, not just the phone
call itself. Remember: all the traffic is going together across the one
OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP
traffic from everything else. Indeed, I could easily make (b) even
stronger by simply having the SIP client open another connection back to
the asterisk host and exchange payloads generated
from /dev/random back and forth while the phone call is
going on.

This is really one of those cases where the simpler the solution, the
more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is
what leads us to the kinds of vulnerabilities described in that article.
VoIP isn’t like email, where you always need an encryption-unaware
delivery mechanism between Alice and Bob. I
believe I’ve described a simple mechanism that can allow anyone with an
Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don’t
we just take the easy and more secure route and do our VoIP this
way?

The collective thoughts of the interwebz