[swinog] Sicherheit von SS7 - mit Schweiz-Bezug

[Matthias Leisi via swinog]

(Resend von der richtigen Absender-Adresse)


https://www.haaretz.com/israel-news/security-aviation/2023-05-10/ty-article-magazine/.premium/global-surveillance-the-secretive-swiss-dealer-enabling-israeli-spy-firms/0188-0005-dc7e-a3fe-22cdf290

The Secretive Swiss Dealer Enabling Israeli Spy Firms

(…)

It leads from the Americas to Africa to South-East Asia, but also to Basel, a 
mediaeval town on the banks of the Rhine and the unassuming home of Andreas 
Fink, a Swiss telecom expert whose unusual skills have placed him at the centre 
of this industry.

(…)

reveal how Fink's systems have served as a conduit for probing and attacking 
phone networks across the globe

(…)

When contacted by this investigation, Fink admitted to working with companies 
and “legally entitled government agencies” as a provider of surveillance 
services.

(…)

Fink's request to Robert was for "SS7 access" and "a bunch of global titles". 
In other words, he wanted a list of phone numbers, belonging to Robert's phone 
company, which could be used to send queries to other networks in other 
countries. 

(…)

-- 
Matthias Leisi
Katzenrütistrasse 68, 8153 Rümlang
Mobile +41 79 377 04 43
matth...@leisi.net <mailto:matth...@leisi.net>___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] ip-plus.net Nameservers dead?

[Matthias Leisi via swinog]

It looks like ip-plus.net nameservers are dead. ns1 times out, ns2 has no IP.

I expect some fallout…

— Matthias
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

Re: [swinog] Geldspielgesetz: 404 COMLOT renamed to GESPA? (or did they get hacked!?)

[Matthias Leisi]

> Still of course, no official word about this change...
> 
> Guess that fixing things is easier than communicating :)

And the list is still hilariously stupid.

It contains interwetten1.com  through 
interwetten10.com , but not interwetten10.com 
 through interwetten24.com 
, which all exist (at least in DNS). Many similar 
schemes in the list.

— Matthias


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SSL Certs question

[Matthias Leisi]

> I still find it funny that Digicert allows "Org Validated" (OV) certs to be 
> issued there. That is one of the few business cases that is left (e.g for 
> bare IP SSL certificates)

And it may make sense for S/MIME certs (even though „LE for S/MIME“ is on the 
horizon, see RFC 8823).

— Matthias
> 
> Greets,
> Jeroen
> 
> 
> 
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Handling of UCE / RBL while minor misconfigurations

[Matthias Leisi]

I think Markus misses the main point of the OP. The question of the OP is not 
whether SPF is a good or bad idea in general.

The question is whether its reasonable to add a blacklisting entry for the 
server IP if you receive a single mail with a non-matching SPF record (ie, 
server with IP a.b.c.d not covered by the SPF for foo.com ). 

My take on this is that this blacklisting behaviour is entirely unreasonable. 

And I agree that it’s questionable why anyone should use a list with such 
unreasonable listing practices (apart from their extortion practices). 
Unfortunately the burden is first shifted not onto the admins responsible for 
such stupid decisions, but on the sending party who must wade through massive 
layers of ignorance and denial.

— Matthias

> Am 08.10.2020 um 09:14 schrieb Markus Wild :
> 
> Hello Urs,
> 
> My take on your problem is the following:
> - SPF is bad and breaks mail delivery, don't use it. But, if someone defines 
> SPF records, and they thus declare they
>  want to shoot themselves into their feet, by all means, I encourage to block 
> mails failing SPF, because that's what
>  domain owners who define SPF records ask for.
> - everyone can setup blocking lists defining the oddest criteria for when an 
> entry gets added. Someone in charge of a
>  mailserver can decide based on his criteria, and his alone, what mails he 
> wants to receive and what mail to reject.
>  He can use whatever resources he wants, including bogus lists such as 
> uceprotect. But, it would be prudent to inform
>  yourself about what exactly you enable before you do so...
> - now, if someone deploys antispam gateways such as those from Sophos, and 
> decides to just click "enable all block
>  lists" or however that menu looks like, and with this enables lists such as 
> uceprotect, then that person just cut
>  their company off from a lot of valid mail. If he wanted to do that, it's 
> his decision, but usually it helps to teach
>  those admins about the errors of their ways, instead of blaming the list 
> provider.
> - I personally consider uceprotect to be a rogue list with utopian views on 
> how mail service works. Their unlist policy
>  could be considered extortion, but the really responsible party is whoever 
> enables such a list on their servers.
> 
> just my personal views:)
> 
> Markus
> 
> 
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Fwd: [dns-operations] Advisory — D-root is changing its IPv4 address on the 3rd of January.

[Matthias Leisi]

-- Forwarded message --
From: Jason Castonguay casto...@umd.edu
Date: Thu, Dec 13, 2012 at 11:54 PM
Subject: [dns-operations] Advisory — D-root is changing its IPv4 address on
the 3rd of January.
To: casto...@umd.edu


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Advisory — D-root is changing its IPv4 address on the 3rd of January.


This is advance notice that there is a scheduled change to the IPv4
address for one of the authorities listed for the DNS root zone and
the .ARPA TLD. The change is to D.ROOT-SERVERS.NET, which is
administered by the University of Maryland.

The new IPv4 address for this authority is 199.7.91.13

The current IPv6 address for this authority is  2001:500:2d::d and it
will continue to remain unchanged.

This change is anticipated to be implemented in the root zone on 3
January 2013, however the new address is currently operational. It
will replace the previous IP address of 128.8.10.90 (also once known
as TERP.UMD.EDU).

We encourage operators of DNS infrastructure to update any references
to the old IP address, and replace it with the new address. In
particular, many DNS resolvers have a DNS root “hints” file. This
should be updated with the new IP address.

New hints files will be available at the following URLs once the
change has been formally executed:

http://www.internic.net/domain/named.root

http://www.internic.net/domain/named.cache

The old address will continue to work for at least six months after
the transition, but will ultimately be retired from service.

- --
Jason Castonguay

Network Integration Software Engineer
Division of Information Technology
University of Maryland
College Park, MD 20742
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDKXLEACgkQA5NiLuECHn4lRQCgoOlYQhq+kXk2Az3nPeN1hUfz
0e4AoKCwp0cLpABJFc/7RV5E/ecfWwoJ
=ktnM
-END PGP SIGNATURE-
___
dns-operations mailing list
dns-operati...@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Change of dnswl.org operating model

[Matthias Leisi]

Hi,

As announced earlier, dnswl.org will change it's operating model.
Heavy users (defined as those doing  100'000 queries/24 hours on
the public nameservers) and vendors of anti-spam products and services
will need a paid subscription.

We are now ready to implement the model and will gradually start to
enforce it. Since we do not know the current users (all we have are
IPs and sometimes hostnames), we will also need to cut off users if
our attempts at identifying and notifying them fail.

The cut off may have two of effects: 1) rsync suddenly stops working
2) queries on the public nameservers are refused. We may be able to
reinstate access on a case by case basis.

As usual, we can be reached at admins/at/dnswl.org (or
office/at/dnswl.org for direct access to the people handling the
subscriptions). All details are available from http://www.dnswl.org/

-- Matthias


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Swinog DNSRBL Whitelist

[Matthias Leisi]

2010/1/26 Mike Kellenberger mike.kellenber...@escapenet.ch:

 The server in question was 194.11.148.23 (outmail43.swisscom.com).

 Or does anyone have a list of swisscom outmail servers?

dnswl.org has: http://www.dnswl.org/search.pl?s=194.11.148.23

-- Matthias


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] swinog Digest, Vol 60, Issue 1

[Matthias Leisi]

Things should be back to normal.

-- Matthias

Am 04.01.10 21:24, schrieb robert.guentensper...@swisscom.com:
 Hi
 
 We're investigating.
 
 Cheers
 Günti
  
 
 -Original Message-
 From: swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch] 
 On Behalf Of supp...@hightechbits.com
 Sent: Monday, January 04, 2010 9:20 PM
 To: swinog@lists.swinog.ch
 Subject: Re: [swinog] swinog Digest, Vol 60, Issue 1
 
 here same problem, bluewin is death
 
 bluewin dns
 195.186.1.110
 195.186.4.110
 
 kind regards mark
 
 
 -Ursprüngliche Nachricht-
 Von: swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch]
 Im Auftrag von swinog-requ...@lists.swinog.ch
 Gesendet: Montag, 4. Januar 2010 21:07
 An: swinog@lists.swinog.ch
 Betreff: swinog Digest, Vol 60, Issue 1
 
 Send swinog mailing list submissions to
   swinog@lists.swinog.ch
 
 To subscribe or unsubscribe via the World Wide Web, visit
   http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
 or, via email, send a message with subject or body 'help' to
   swinog-requ...@lists.swinog.ch
 
 You can reach the person managing the list at
   swinog-ow...@lists.swinog.ch
 
 When replying, please edit your Subject line so it is more specific than Re: 
 Contents of swinog digest...
 
 
 Today's Topics:
 
1. Bluewin DNS problems (Benjamin Schlageter)
2. Re: Bluewin DNS problems (Flavio Tischhauser)
3. Re: Bluewin DNS problems (Umberto Annino)
4. Re: Bluewin DNS problems (Adrian Ulrich)
5. Re: Bluewin DNS problems (Simon Leins)
6. Re: Bluewin DNS problems (Benjamin Schlageter)
7. routing quirks with IP-MAN (Marc SCHAEFER)
8. Re: Bluewin DNS problems (Romain Bourdy)
 
 
 --
 
 Message: 1
 Date: Mon, 04 Jan 2010 20:16:14 +0100
 From: Benjamin Schlageter b.schlage...@ebm.ch
 Subject: [swinog] Bluewin DNS problems
 To: swinog@lists.swinog.ch
 Message-ID: c767fd0e.28c5%b.schlage...@ebm.ch
 Content-Type: text/plain; charset=iso-8859-1
 
 Hi
 
 Anybody knows something about big DNS troubles with Bluewin ADSL/VDSL?
 As I saw, my router can?t resolve any domains... Lucky I got some other dns 
 servers =)
 
 Cheers,
 Benjamin
 -- next part --
 An HTML attachment was scrubbed...
 URL:
 http://lists.swinog.ch/public/swinog/attachments/20100104/d62048f8/attachme
 nt-0001.htm
 
 --
 
 Message: 2
 Date: Mon, 4 Jan 2010 20:37:03 +0100
 From: Flavio Tischhauser ftischhau...@gmail.com
 Subject: Re: [swinog] Bluewin DNS problems
 To: Benjamin Schlageter b.schlage...@ebm.ch
 Cc: SWINOG swi...@swinog.ch
 Message-ID:
   9bb210121001041137sc5835f3v55035b859e007...@mail.gmail.com
 Content-Type: text/plain; charset=windows-1252
 
 On Mon, Jan 4, 2010 at 20:16, Benjamin Schlageter b.schlage...@ebm.ch
 wrote:
 Anybody knows something about big DNS troubles with Bluewin ADSL/VDSL?
 As I saw, my router can?t resolve any domains... Lucky I got some 
 other
 dns servers =)

 
 Same here, also receiving IMs from other swisscom customers telling me that 
 their internet is broken.
 
 regards
 
 Flavio
 
 
 
 --
 
 Message: 3
 Date: Mon, 04 Jan 2010 20:37:25 +0100
 From: Umberto Annino pr...@gmx.ch
 Subject: Re: [swinog] Bluewin DNS problems
 To: swinog@lists.swinog.ch
 Message-ID: 20100104193725.146...@gmx.net
 Content-Type: text/plain; charset=iso-8859-1
 
 I don't KNOW anything about it, but I am experiencing the same here, since 
 about one hour. Some sites respond well, others not or only very shaky or 
 partial.
 
 DNS query time between 500-700ms.
 
 I particularly like how bluewin is capable of presenting me a NICE and 
 easy-to-find status page of their service - NOT. stone age or what?
 
 regards,
 Umbi
 
  Original-Nachricht 
 Datum: Mon, 04 Jan 2010 20:16:14 +0100
 Von: Benjamin Schlageter b.schlage...@ebm.ch
 An: swinog@lists.swinog.ch
 Betreff: [swinog] Bluewin DNS problems
 
 Hi

 Anybody knows something about big DNS troubles with Bluewin ADSL/VDSL?
 As I saw, my router can?t resolve any domains... Lucky I got some 
 other dns servers =)

 Cheers,
 Benjamin
 
 
 
 --
 
 Message: 4
 Date: Mon, 4 Jan 2010 20:40:53 +0100
 From: Adrian Ulrich swi...@blinkenlights.ch
 Subject: Re: [swinog] Bluewin DNS problems
 To: swinog@lists.swinog.ch
 Message-ID: 20100104194054.0d0308...@echelon.blinkenlights.ch
 Content-Type: text/plain; charset=US-ASCII
 
 Anybody knows something about big DNS troubles with Bluewin ADSL/VDSL?
 
 No: Bluewin-DNS is fine for me. But i had some ADSL problems on 2-3. Jan:
 I had about ~30% packet loss with any (?) gateway in 195.186.252.0/24.
 
 Re-Connecting until i got a gateway in the 253-range fixed the problem for me
 
 Regards,
  Adrian
 
 
 
 --
  RFC 1925:
(11) Every old idea will be proposed again with a different name and
 a different presentation, regardless of whether 

Re: [swinog] Vorratsdatenspeicherung

[Matthias Leisi]

2009/7/12 Ihsan Dogan ih...@dogan.ch:

 Das würde aber schon fast nach einer Initiative schreien. Ging das
 eigentlich durch den Nationalrat?

Ähm, BÜPF/VÜPF sind ganz normal durch die Gesetzgebungsmaschinerie
gegangen. Hier geht es im Kern um Art. 5 Abs. 2 BÜPF
(http://www.admin.ch/ch/d/sr/780_1/a5.html):

| Die Auskünfte [können] auch sechs Monate rückwirkend angeordnet werden.

Das Büchlein ist die Umsetzung/Konkretisierung dieser Bestimmung.
Interessante Lektüre dazu ist auch Art. 23-27 VÜPF
(http://www.admin.ch/ch/d/sr/780_11/).

-- Matthias

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Post from Canton de Vaud

[Matthias Leisi]

Oliver Bollisger schrieb:

 but what is the best method? blocking ip traffic to the site can also
 mean to block legitimate traffic to a shared hosting server!?

Filter the traffic for specific IPs/networks/etc (eg by playing some BGP
games) through transparent proxies and redirect forbidden traffic to a
suitable target (or /dev/null).

Yes, that is an engineering challenge, but feasible.

Yes, that is a legal challenge, but it can be done in ways compatible
with constitutional rights and contractual obligations.

Yes, that contradicts many fundamental principles of how many people
perceive the Internet, but that is a weak argument in public discussion.

Yes, judges from the canton of Vaud seem to be specifically incompetent
and impertinent, but this can not be corrected by whining on a techie
mailing list.

Note that I'm far from endorsing or supporting such decisions, but that
I'm just asking for more effective ways to unmask the short-sightedness
of the judges orders.

-- Matthias
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Netclean - news

[Matthias Leisi]

Fredy Kuenzler schrieb:

 From
 http://www.blogg.ch/index.php?/archives/785-Netclean-Whitebox-effektive-Methode-gegen-Kinderpornografie-im-Netz.html
 
 Netclean Whitebox funktioniert zweistufig: 1. wird via BGP4 die Liste
 der verdächtigen IP Adressen in die Routingtabelle eingepflegt. 
 Derzeit sind das um die 450 IP Adressen. Traffic von diesen Websites 
 wird auf die Whitebox umgeleitet. Auf dieser erfolgt 2. die DNS resp.
 HTTP Inspection, und die Whitebox ist damit in der Lage, zwischen 
 illegalem und harmlosen Inhalt zu unterscheiden, der sich zufällig an
 der selben IP Adresse befindet.

So it works kind of like eg Arbor Networks' DDoS protection mechanism
(redirect some traffic using BGP, deep packet inspection after packet
reassembly), coupled with data from an uncontrollable source (which is
generally believed to be some sinister government agency infiltrated by
oppressive political regimes).

It's interesting it took so long for commercial products to appear for
the technically obvious solution.

It will be interesting to see how fast well-meaning politicians and
paranoid pseudo police-men will want to filter all that nasty illegal
music from the net. And how long it will be before such machinery is
mandatory for all ISPs.

The excuse that there is no technical solution is gone - it was a lie
all along the way, and most techies knew. Now it's time to face the
consequences.

-- Matthias
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] The truth about UCEPROTECT-Blocklists

[Matthias Leisi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Peter Keel schrieb:

 And yes, autoreplies are bad. This also includes out-of-office
 notifications. If you allow them out to the Internet at large, you're
 almost as bad as the next pill spammer.
 
 Try to explain that to the users at large and _any_ management. 

Do you want to send email, or do you want to send Out-of-Office replies?

- -- Matthias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFIt5h+xbHw2nyi/okRAnbSAKCZwq2vEHGbdkLWFdUjvHDoZlCkDQCfZgT/
XB5HpBEhEQrSdALcq8Dvuk0=
=r9AG
-END PGP SIGNATURE-
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] dnswl.org ?

[Matthias Leisi]

Per Jessen wrote:

 Since such ranges are usually not as trustworthy as /32s of
 well-respected mailserver operators, dnswl.org lists such ranges with
 a score of none; for all practical reasons, this should translate
 into do not greylist, since there is most likely a legitimate
 mailserver at the other end who will retry anyway.
 
 This sounds like a pretty good idea, but judging by the size of the
 rbldnsd file, it's not very popular?  Only 4317 entries. 

There is definitely room for growth ;-)

dnswl.org data grows through three methods:

1) Company/organisation/individual/... mail administrators telling us
about their outgoing mailservers: http://www.dnswl.org/request.shtml

2) Importing/joining whitelists of trusted(!) sources. Currently, this
includes Swinog, ABUSES[1], and a financial services company.

3) dnswl.org administrators finding good mailservers by themselves (eg
by looking at incoming log files, user feedback etc)

You are all welcome to help! dnswl.org heavily relies on the
collaborative effort -- instead of everybody maintaining their own
lists, we can as well join forces :)

As to the popularity (see http://www.dnswl.org/mrtg/):

There are currently DNS requests from more than 330 distinct /24s (which
is roughly equal to distinct sites using dnswl.org data).

We have detailled usage logs/stats from 4 out of 7 DNS servers for the
list.dnswl.org zone. These 4 servers handle an average of above 15'000
queries/minute.

That's both not very impressive, but I expect usage to grow considerably
as soon as SpamAssassin 3.2 is released (currently in RC1 status), which
will include dnswl.org-based rules by default.

-- Matthias

[1] http://www.rediris.es/abuses/eswl/en/

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: AW: AW: AW: [swinog] Whitelist website

[Matthias Leisi]

Radek Mrskos wrote:

 Ok, but this is exactly what do not belongs to this list. *.mail.ru (many
 others also) is a spamer domain.
 If the postmaster of *.rr.com, *.net.br, *.com.br calls you to enter his
 ranges, will you enter it?

194.67.23.0/24 does not equal the full set of *.mail.ru hostnames.

Similarly, dnswl.org contains three /24s for uol.com.br (see
http://www.dnswl.org/search.pl?s=3633). Now this is not a statement that
uol.com.br is all nice and cosy, but it's a statement of the fact that
the postmaster for uol.com.br told us that these are the ranges for the
mailservers (and we verified that using eg senderbase.org).

Since such ranges are usually not as trustworthy as /32s of
well-respected mailserver operators, dnswl.org lists such ranges with a
score of none; for all practical reasons, this should translate into
do not greylist, since there is most likely a legitimate mailserver at
the other end who will retry anyway.

Yes, whitelisting incurs the risk of missing some spam. But this risk is
usually lower than catching a non-spam in a spamfilter.

-- Matthias

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: AW: [swinog] Whitelist website

[Matthias Leisi]

 Of course, but you got the hostname wrong. It's http://dnswl.swinog.ch aka
 http://antispam.imp.ch/swinog-dnsrbl-whitelist

 But not only Swiss Mailservers, this would be a bit useless :-)

And of course there is also dnswl.org ;-) [Note that dnswl.org data also
includes the Swinog whitelist, updated (ir)regularly.]

-- Matthias (one of [EMAIL PROTECTED])


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Mail server - Unix

[Matthias Leisi]

Jeroen Massar wrote:

 dns was not really questioned, but I would prefer djbdns
 (+patches, again) or bind.
 
 Patches, patches, patches. Bind9 is fine (and actually what I usually
 use) but pdnsnds are simply faster, thus for scalability I would go for
 those, then again it depends on ones needs.

Given the potentially high DNS traffic (all those xBL lookups), a
dedicated caching DNS resolver may make sense. Additionally, you should
consider running a local rbldnsd for mirrored zones (proxying from the
resolver to rbldnsd).


  - amavis + clamav  Spamassassin using milter inline in postfix
 Seem both to be just 'the standard antivir and antispam' solution
 
 There is afaik nothing better, especially in combo with:

Detection rates of ClamAV are pretty low. If you want to advertise
virus protection as a feature, you may want to integrate at least one
additional scanner.

-- Matthias

-- 
http://www.dnswl.org/ - Protect against false positives

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

[Matthias Leisi]

Daniel Lorch wrote:

  Are you sure? Isn't that exactly the point of asymmetric cryptography?
  The way I see it, TLS and SSL work like this (analogous to PGP):

You're almost right.


  1. The client connects to the server and obtains the server's public
 key. The public key is a mathematical recipe to encode (but not
 decode) a message for a specific recipient.

ACK.

  2. Using this public key, the client encodes the message (cleartext -
 ciphertext). Now the interesting part is, that the client isn't able
 to decode this cipher text he just encoded, because he doesn't have
 the private key (that's why it is also necessary to always encrypt
 PGP messages to yourself, otherwise you won't be able to read them
 later on in your sent box).

SMTP/TLS does not encrypt individual messages - as it's name implies, it
works on the *transport* layer. And there, the public key exchange is
used to agree on a symmetric session key.

Btw., neither server nor client public keys would technically be
required; anonymous DH would work as well (although it would not make
much sense...).


  I could now connect to the mail server, obtain the public key and
  generate as many cleartext/ciphertext pairs as I want and I still would
  not be able to guess the private key from that information.

Of course, known-plaintext, replay and similar attacks on TLS and SSL
are theoretically possible. However, I have not heard of practically
possible or generally successful attacks.

-- Matthias


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

[Matthias Leisi]

Hi all,

The subject says it all: do you know which providers support TLS (the
technology formerly known as SSL) for SMTP, POP and/or IMAP for their
residential or small-office dialup/broadband customers?

If you are a provider yourself and you do not offer it: Are there
particular reasons? Is it a conscious decision not to offer it or is it
that just nobody asked yet?

Thanks,
-- Matthias
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Bluewin MX - mail-fwd.mx.hostcenter.com

[Matthias Leisi]

 SMAIL SMTP-Send MX = mail-fwd.mx.hostcenter.com. SMTP = mhs.ch From =
 [EMAIL PROTECTED] To = HIDDEN Failed !

 SMTP-Error = 451 Exhausted MX records for domain HIDDEN

Seen here as well for a handful of domains, but not all transactions
through mail-fwd.mx.hostcenter.com are to be affected. First occurrence
here is 20060206 12:39:49

-- Matthias


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog