back to article A simple SSL tweak could protect you from GCHQ/NSA snooping

An obscure feature of SSL/TLS called Forward Secrecy may offer greater privacy, according to security experts who have begun promoting the technology in the wake of revelations about mass surveillance by the NSA and GCHQ. Every SSL connection begins with a handshake, during which the two parties in an encrypted message exchange …

COMMENTS

This topic is closed for new posts.

Page:

Stop

Was this news?

I've written stuff to extract data from SSL/TLS streams after the fact, assuming access to the server's private key. Doesn't work with DH. DH/DHE/ECDHE are specifically disallowed in FIPS 140-2 and other federal/government standards for a reason - you can't audit them.

So if you care about securing your SSL/TLS comms against future snooping then enable the cipher-suites that use these keygen mechanisms.

Of course if it's anything important and you really don't want the government agencies to look, then you'll be needing to run your own certificate authority too (no, not just a self-signed server cert), in order to thwart MITM attacks. What, you thought the cert authorities wouldn't just issue any cert the government agencies feel like? LOL.

8
3
Holmes

Re: Was this news?

That's not how certificate issuance works. You generate they key and send them a certificate signing request with your public key parameters. The cert. auth. never knows your private key, for obvious reasons.

5
2
Unhappy

Re: Was this news?

But all you know is that this certificate for "www.mysite.com" was signed by Verisign.

Verisign can sign any number of certificates for the same site for whatever private key they like, as you don't know it either.

Sure, its fine for securing stuff when you control both ends of the connection (like a vpn back to your company) where you can keep track of the public key as well.

Otherwise you'll have to use something else, like something that keeps track of public keys and tells you if they change. Then how do you know the change isn't normal? Go on the internet...Kind of chicken and egg there? Use a third party validator like Convergence (which uses the internet to check...dunno if they build in fixed public keys)?

In any case, the public/private key mechanism breaks down when the adversary not only has access to your communications, but also controls the courier system, address book and your third party verification service you use to set up the exchange in the first place.

5
0
Bronze badge
WTF?

Re: Was this news?

"In any case, the public/private key mechanism breaks down when the adversary not only has access to your communications, but also controls the courier system, address book and your third party verification service you use to set up the exchange in the first place".

Bullfood. The only weaknesses in PKI are a) losing control of your private key, don't do that, or b) asking for someone's public key which you don't have yet. This is only done once and saved (until it expires or is revoked), for exactly this reason.

IN ANY EVENT, PKI is not used for session key negotiation in SSL, it's used for authentication.

3
0
Bronze badge
Big Brother

Re: Was this news?

Well, you do have one point. If the NSA does a man in the middle, and they have a way of creating certificates signed by a recognized root CA for the site you're connecting to, they can see everything going on. Of course, in that situation, they can fake each side of the DH (if effect wiring themselves into the conversation), and you're boned.

Do the three letter agencies do that? I sincerely doubt it as a matter of routine. But I wouldn't be surprised if they had malware that plants false root CAs on a target's cert store, and can have your ISP route your traffic through servers they control if they want to eavesdrop. But it would be hard to do without leaving footprints that th target could find if they had any brains at all.

5
0
Boffin

Re: Was this news?

Pet Peeve: "Do the three letter agencies do that [man in the middle]?"

The context here was the stored traffic and not the live flow. Therefore man in the middle would not be feasible unless the tap can also redirect (not split) specific traffic through their own infrastructure on request. But technically this would modify active routing tables: highly unlikely. The tap at the main exchange has to be passive. That said, there are other possibly access points up or downstream for block and insert which could help to achieve this if such target was to be selected.

1
0
FAIL

@ JeevesMkII

"That's not how certificate issuance works. You generate they key and send them a certificate signing request with your public key parameters. The cert. auth. never knows your private key, for obvious reasons."

Hi again.

I know exactly how certificate issuance works because I've done it. And I know very well that if the likes of Verisign issued a certificate to the NSA with the signing bit switched on then they could sign any certificate for any server they felt like and perform man-in-the-middle attacks against any system that had (for instance) verisign's root certificate installed. The certification authority never knows your private key because it's irrelevant to a MITM attack. You only need to get the client to accept that your cert is signed by a trusted root.

I know this because I've written software to do this (successfully) and familiarised myself with the SSL and TLS RFCs. Perhaps you should do the same and investigate the role of the authorities in the chain of trust before you hold forth on issuance procedures.

3
0
FAIL

Re: Was this news?

>> Bullfood. The only weaknesses in PKI are a) losing control of your private key, don't do that, or b) asking for someone's public key which you don't have yet.

Bullshit.

The weakness with the PUBLIC authority structure is you have to trust the public authorities, and sometimes you can't. You can request a key for www.example.com because you own it, but if any of the authorities trusted by your browser issue another certificate to someone else for www.example.com, then they are enabled to perform MITM attacks. Or if they allow a signing certificate then whoever gets that can sign a cert for any server they like, and MITM anything.

>> IN ANY EVENT, PKI is not used for session key negotiation in SSL, it's used for authentication.

Well, that rather depends on the cipher suite you use, which is rather the point of this article.

3
0

Re: Was this news?

If a tinpot dictatorship like Iran does this regularly (google "comodo iran" for more details), you can rest assured our benevolent voyeurs do so as well.

1
0
Thumb Down

Re: Was this news?

"Bullfood. The only weaknesses in PKI are a) losing control of your private key, don't do that, or b) asking for someone's public key which you don't have yet. This is only done once and saved (until it expires or is revoked), for exactly this reason.

IN ANY EVENT, PKI is not used for session key negotiation in SSL, it's used for authentication."

So, yeah, the weakness is when you ask for a public key, that's when the MITM attack works. In a standard internet situation you ask for the public key each time, you don't store it unless you use one of the secondary controls I detailed. Once the MITM attacker has pointed you at their server instead, using their public key, you can start up whatever encryption negotiation with them you want,. Turns out as they provided the session negotiation they can read the traffic, so whatever mechanism you use it doesn't help you against a live MITM attack.

0
0
WTF?

Re: Was this news?

Great - another "Why is this news? (*sniff*) I've known this obscure technical fact for years. sure everyone knows it?"

I'm just waiting for the El Reg article on how the convert-to-decimal instruction on the IBM Mainframe oddly has the usual order of source and destination operands reversed. then I can say "Why is this news? *sniff*. Doesn't everyone know IBM Assembler?". If this happens, please feel free to reply "No they don't and f#ck off".

0
1
Silver badge

"In recent years, we've seen DHE fall out of fashion. Internet Explorer 9 and 10, for example, support DHE only in combination with obsolete DSA keys,"

Well, given recent revelations, perhaps it was that the NSA didn't want DH as standard, and leaned on Microsoft.

19
0
Bronze badge
FAIL

That statement is a big pile of bullfood. DHE out of fashion? Internet Explorer having anything to do with establishing the connection? What the heck is this guy talking about?

1
0
Bronze badge
Boffin

This sounds bogus. Asymmetric crpyto is used for authentication (to verify the site you're going to isn't spoofed), but the session keys are negotiated by a Diffie-Hellman key exchange, which as far as I know has always been perfect forward security, since you can eavesdrop on the entire exchange and not learn a thing about what key was negotiated.

Are there SSL modes that don't use DH? I didn't think so.

0
0
Anonymous Coward

Well

There are ssl modes that don't use DH but they're not favoured. "openssl ciphers -v" will give you a list of ciphers in preference order and the top ones for both 0.9.8x (mac) and 1.0.1e (fedora) use DH.

I can understand IE trading security for performance though...

0
0
Bronze badge
Facepalm

Re: Well

IE has its own ssl implementation built into it? Really? That seems like a really, really bad idea.

0
0
Boffin

Asymmetric crpyto is used for authentication (to verify the site you're going to isn't spoofed), but the session keys are negotiated by a Diffie-Hellman key exchange

When you do PK authentication you can establish the session key "for free" as a side effect. I guess this is usually done because it somewhat simplifies the handshake.

0
0
Bronze badge
Holmes

It's NOT usually done. The most common SSL modes use DH for key exchange. I have no idea where this "out of fashion" thing comes from. DH is vital for forward security, that's why it was developed.

0
0
Gold badge

Re: Well

"IE has its own ssl implementation built into it? Really? That seems like a really, really bad idea."

It sure is, but this is the Microsoft way. This really is one reason Microsoft has had so many security problems over the years -- the lack of code reuse where it makes sense. I mean, they'll fix some JPEG handling flaw -- in 5 different places in the code -- then find out they missed another 3, and that these other few locations have a *different* JPEG handler with different bugs.

Of course, in the case of IE, they will not of course use OpenSSL... Microsoft probably (despite being required by EU decree to keep IE seperate from Windows) expects IE to have the definitive SSL implementation for Windows, and people wanting to use SSL to call the SSL support in IE.

0
0
Anonymous Coward

Re: Well

>> There are ssl modes that don't use DH but they're not favoured.

Actually they are, particularly by government agencies.

0
0
Bronze badge
Holmes

Re: Well

Actually, it is not IE which implements cryptographic operations, it is core of the operating system (i.e. Windows). Although IE, like any other user program, gets to choose how to use this cryptography, and unlike any other user program, gets to influence the OS team what's available and how it's implemented.

0
0

Indeed, my Apache with default configuration handshakes with DHE. However, this article explains the performance problem with DH, and solution that is apparently adopted by Google now: they handshake with ECDHE at the moment.

0
0
Silver badge

It is a lot more involved and complicated than you think or have not yet been told

This feature has become a serious liability in the era of mass surveillance.

Surely it be better used as added exciting features in these eras of mass surveillance …… SMARTR Mentoring and AIMonitoring.

Sharing ESPecial Knowledge for the Way Out Into the Wild and Open.

And that's NEUKlearer HyperRadioProActive IT Systems Testing for GCHQ Compatibility/SWIFT Responses.

And you may like to consider that CyberSpace is long ago a Private Pirate Place and has its Super Space Travellers Exchanging Gifts of Luscious Awe Ware.

Home Territory to the Nymph and Satyr, who are both pleasurably satisfying but insatiable. :-)

To Control and Power Love …… Now that would be a Heavenly Opportunity with Perks not to be Denied to Love Power Controllers.

The very nature of love ensures and guarantees it be so, and it is only natural and to be fully expected of intelligence which has passionate insatiable drivers in search of the Perfect KISS for Climactic Union with Others of the Species.

And if you want to know what has happened there, El Reg, you can tell everyone and/or anyone who asks, a node was docked and locked to our servers.

4
1

Good luck trying to secure your traffic against US government snooping. US companies supply most network kit, most pc's are running windows and US companies run most of the trusted root certificate authorities.

10
0
Anonymous Coward

US companies run most of the trusted root certificate authorities

Yup - that's your starting point for security. Avoid like the plague.

2
0
Silver badge

The devil you know is still the devil

Re: "US companies run most of the trusted root certificate authorities."

Most of holders of root certificates are among the entities I trust the *least* to protect me.

0
0
Silver badge

A couple of drops...

1878: A couple of drops of this here snake oil will protect you against any illness, the IRS and bankruptcy, boy!

1968: Just hold this crystal in your right hand, it will protect you against the FBI and bad karma, man!

2013: All you need to do is implement this SSL handshake and it will protect your computer against any acronym which tries to collect your data, mate.

2
0
Anonymous Coward

Any expectation of privacy in today's communications on the Internet are gone. Governments have access to your emails, phone calls, bank records, travel itineraries, family history's, lists of your friends, what they do, where they go and what you talk about. Your phone and car carry GPS history of your travels. And that is what we KNOW about.

The time to secure communications was twenty years ago. Instead, nothing was done and state sponsored keys, algorithms and protocols were introduced. Commerce laws were enacted to outlaw the schemes that would have guaranteed privacy and now here we are. Besides, they don't NEED to break your encryption when companies you trusted, ISP's and telecoms hand over the plain text regardless.

The only thing we can do is revamp the entire standards we use on a daily basis. The cost would be exorbitantly expensive and in the end any "official" replacement will be just as flawed and easy to crack / track.

Welcome to the world of secret laws and star chamber justice. Go ahead and vote for someone else next time. See how fast the system changes. Once governments get power, they seldom walk away from it.

1
1

Star Chamber

You over malign the Star Chamber. In some ways its biggest problem was that it was efficient. Everything was done "on the papers", so that come judgement time, there could be a rapid number of judgements that seemed to be rather arbitrary, but were in fact reasonably well considered.

I remember a historian looking through the cases within the last fifty years or so and coming to the conclusion that the decisions of the star chamber were not particularly unfair, considering the times. I forget which book it was in, alas.

Secret laws on the other hand: not such a nice thing.

0
0
Anonymous Coward

So simple!

That the Reg doesn't even tell us how to do it.

1
2
Anonymous Coward

Re: the Reg doesn't even tell us how to do it.

Well I'm certainly still in the dark about how to tell whether my browser is/isnot likely to be trying to run sessions with DH rather than falling back to the less secure sort.

Lets pick e.g. firefox: what does it usually try to do? while ssl'ing, can I check so see what sort of ssl is being used? can I get it to warn me about certain ssl schemes being used/demanded by the server? Perhaps there's a plugin that would help?

I'm certainly no wiser about the user end, i.e what my browser is doing.

0
0
Anonymous Coward

willing participant

"Although the use of Diffie-Hellman key exchange eliminates the main attack vector, there are other actions a powerful adversary could take," Ristic warns. "For example, they could convince the server operator to simply record all session keys."

Well if the adversary was able to obtain the cooperation of the server operator, why wouldn't they simply have the server operator log the desired unencrypted info?

3
0
Bronze badge

Key exchange for dummies.

Let me get this straight because I always just guessed at how SSL works and am obviously wrong...

- Computer A contacts computer B sending A's public key.

- B sends A a randomly generated session key encrypted using A's public key.

- A decrypts key using it's private key and now both machines have the secret session key.

- A and B communicate using the secret session key.

- A and B disconnect.

- A and B destroy the secret session key.

- Future connections use a different randomly generated session key.

How do you get the secret session key after the connection has terminated?

0
0
Angel

Re: Key exchange for dummies.

http://www.theregister.co.uk/2013/06/03/quantum_boffins_get_spooky_with_time/

0
0
Anonymous Coward

Re: Key exchange for dummies.

No, the MITM attack happens during the first exchange. If Computer A only THINKS it talks to B but it's in reality N(SA) who then in turn talks to B, A will never know that the comms was basically cleartext to N. For N to pretend it's B it needs a cert that the browser will accept during session setup, and it's there the support from root CAs comes i play. If they issue a cert that confirms a valid "B entity your session is compromised.

You are right insofar that it's a lot harder post event, but all you need is a DNS tweak and a cert and you're in (the intercept) business. This is partly because the SSL cert was never meat to act as a site identifier, that's something that was dreamt up later.

BTW, this is also why you should not have your DNS reg and management in the US.

2
0
Boffin

Re: Key exchange for dummies.

if you have access to private key (a search warrant, 15 minutes if work for a TLA and can say PATRIOT) you can do exactly the same the A computer does in step 3 even years after the original communication took place

there's no need for esoteric software, even wireshark can do this

but it's impossible to do if you use DH (either log based or EC based) since the key is never sent over the link and both server side and client side random variable used to derive the key is single use and not tied to certificate or private key in any way

1
0
Happy

Re: Key exchange for dummies.

>> B sends A a randomly generated session key encrypted using A's public key.

>> How do you get the secret session key after the connection has terminated?

'C' takes a length of pipe and a couple of hard men, retrieves A's private key and decrypts the session key message, therefore unlocking all the rest of the data with the session key.

Diffie-Hellman gets around this by using clever maths to allow two sides of a conversation to derive the same key *without exchanging enough information over the wire to rebuild the key later*. It's a work of genius and I highly recommend reading about it on Wikipedia.

0
0

This post has been deleted by its author

Silver badge

Re: Key exchange for dummies.

">> B sends A a randomly generated session key encrypted using A's public key.

>> How do you get the secret session key after the connection has terminated?

'C' takes a length of pipe and a couple of hard men, retrieves A's private key and decrypts the session key message, therefore unlocking all the rest of the data with the session key."

I'm probably going to make a fool of myself here, but I'll say it anyway :-)

In the above, why doesn't "A" create a new private/public key for each session (well, not A-the-person, but A-the-software) -- never storing the private key on permanent store? Then there is no private key for "C"'s thugs to beat out of "A"

0
0
Bronze badge

Re: Key exchange for dummies.

In the above, why doesn't "A" create a new private/public key for each session (well, not A-the-person, but A-the-software) -- never storing the private key on permanent store? Then there is no private key for "C"'s thugs to beat out of "A"

Exactly what I was thinking, why are these keys kept beyond the life of the session?

Also, the article refers to getting the key off the server, B in my example, however I never give B the private key, unless it means the session key, which should be deleted after the session ends.

0
0
Happy

Re: Key exchange for dummies.

>> In the above, why doesn't "A" create a new private/public key for each session (well, not A-the-person, but A-the-software) -- never storing the private key on permanent store? Then there is no private key for "C"'s thugs to beat out of "A"

OK, so the public/private key pair are used for authentication. We don't generate new ones each time, as a rule, because A's public key needs to be accepted as secure and trusted by B. This can be achieved by sharing it in some secure way ahead of time or by having a mutually trusted authority sign it. If you don't do this B can't be sure they are talking to A, B might be talking to M who is running a man-in-the-middle attack.

You could certainly reduce the lifetime of private keys and securely delete them after a while, that might be good practice, but it's not really practical to make a new one each connection.

And this is basically what Diffie Hellman is for, to make session keys that can't ever be regenerated when the connection is dead, so C has no recourse to pipe and gorillas :)

0
0
Stop

Re: Key exchange for dummies.

>> Exactly what I was thinking, why are these keys kept beyond the life of the session?

OK, so the RSA keys need to be kept because they are used for authenticating who you're talking to. Without them you're vulnerable to MITM attacks.

>> Also, the article refers to getting the key off the server, B in my example, however I never give B the private key, unless it means the session key, which should be deleted after the session ends.

I think the point is that the server may be forced by non-technological means to give up their private key. Or they may be hacked. Without (EC)DH(E) you could use this to decrypt any previous traffic dumps you happen to have of comms between that server and any clients.

0
0
Bronze badge

Re: Key exchange for dummies.

OK, so the RSA keys need to be kept because they are used for authenticating who you're talking to. Without them you're vulnerable to MITM attacks.

That's true for authenticated keys, but that should be done after an encrypted channel has been formed and over the encrypted channel. Otherwise you're revealing who is conversing in plain-text (the signatures themselves).

Besides if we're talking web communication then the client (A) isn't verified. The login process is presumed to achieve that.

I think the point is that the server may be forced by non-technological means to give up their private key.

But in my example the session key isn't encrypted with B's key, it's encrypted with A's public key, and as A's key isn't verified it can be temporary. If A uses a permanent key then yes, A could be strong-armed, but A is the client.

Actually, B doesn't need a public/private key at all in that example.

I'm assuming A has a public/private key pair, and the session key is a randomly generated symmetric key.

I'm sure there's a stack of crypto-geeks cringing at my inability to understand why this is an issue. If so, my apologies.

0
0

Re: Key exchange for dummies.

"That's true for authenticated keys, but that should be done after an encrypted channel has been formed and over the encrypted channel. Otherwise you're revealing who is conversing in plain-text (the signatures themselves)."

This is not how SSL works, nor is it a problem it tries to solve. It's perfectly obvious who is conversing because (over the public internet) you can see the endpoints anyway. And signed certificates will be passed to anyone that connects to the server, so it's pretty irrelevant to this domain (though probably not all domains) who gets to see it and we don't care if it's secret or not.

But in my example the session key isn't encrypted with B's key, it's encrypted with A's public key, and as A's key isn't verified it can be temporary. If A uses a permanent key then yes, A could be strong-armed, but A is the client.

I think I became confused over who A and B were. OK, lets flesh out your example a bit -

The client is A and the server is B. It's not mentioned but we'll assume that RSA authentication is used to rule out MITM attacks (right?) at the start of the connection in the usual way. The Key pair used here will be Kb0 (private) and Kb1 (public) and Kb1 is signed. So now we know who is talking to who and we're left with the problem of establishing a session key in a way that cannot be decoded from a traffic dump afterwards.

The 'pure' RSA method is for A to use Kb1 to encrypt a session key, Ks, and send it to B which decrypts using Kb0. If Kb0 is ever discovered then Ks can be recovered and the whole session can be decrypted.

Your proposal is that the client generates a new Public/Private key pair (Ka0 and Ka1) and sends the public part (Ka1) to the server. The server uses this to encrypt a random session key Ks, sends it back to the client which decrypts using the private key (Ka0), so now encrypted comms can commence. Ka0 and Ka1 are immediately erased so Ks can't be decrypted in future. Correct?

The method used in the article and in practice is to use DH, send some parameters over the wire, and come up with Ks in a way that never exchanges Ks or enough information to derive Ks over the wire.

I can see no reason your solution wouldn't work (this doesn't mean it's perfect, there may be good reasons it isn't, I'm an amateur crypto-geek not a pro). It does send Ks over the wire so if RSA factorisation ever gets 'solved' you may have the same issue. This seems unlikely, though you'd want to use a long key to be sure.

The reason you might not deploy it in practice is that generating RSA key pair Ka0 and Ka1 is a non-trivial computational expense for the client and can take a number of seconds even on a relatively modern machine, greatly extending the TLS handshake period. Encrypting with them is also somewhat expensive for the server. DH is comparatively trivial and fast for both sides.

So AFAICT there's no cringeing needed, your scheme would work but is slow. AFAICT.

0
0
Bronze badge

Re: Key exchange for dummies.

Your proposal is that the client generates a new Public/Private key pair (Ka0 and Ka1) and sends the public part (Ka1) to the server.

Yes, although I wasn't going to worry too much about destroying the client's private key.

I see the problem here is simply that the key chosen, is long term, and the server's key rather than the client's.

The advantage of using a client key is that you increase the number of keys in the system.

0
0

Re: Key exchange for dummies.

OK so with a non-ephemeral client key pair, you would make life a lot more tricky for a potential eavesdropper because they'd have to obtain the client private key Ka0 for each client they were interested in. However if Ka0 can be obtained then potentially all the Ks used by that client to encrypt comms to multiple servers could be exposed. By changing the client key pair every so often (daily?) you could mitigate this risk somewhat.

It does rely on client security rather than server security, and where you put your trust there probably depends on your politics.

That said, I think the DH kex scheme is superior because there is no key information retained between connections, and Ks is never broadcast at all.

0
0
Bronze badge

Re: Key exchange for dummies.

That said, I think the DH kex scheme is superior because there is no key information retained between connections, and Ks is never broadcast at all.

Yes, except in effect a public/private key pair is created at each connection. Which we feel is computationally expensive, and if it's not lends itself to being brute forced.

If you look at wikipedia's explanation of DH (it has a useful analogy: http://en.wikipedia.org/wiki/File:Diffie-Hellman_Key_Exchange.svg) then you can view the colours passed to the other person as being public keys and Alice and Bob's secret colours as private keys and you have the same problem don't you? All you need is one of the "secret colours" and you're in.

So it only works if the secret is regularly changed doesn't it? If one of the secrets is stored then it too will break in exactly the same way. Which is fine where the key generation is computationally light.

0
0

Re: Key exchange for dummies.

>> Yes, except in effect a public/private key pair is created at each connection.

Kind of. It's key material rather than actual keys.

>>Which we feel is computationally expensive, and if it's not lends itself to being brute forced.

This is not true of DH, no, it's computationally very cheap and is not really prone to brute force. RSA keys are computationally expensive to create because (IIRC) of the fact they are very long co-primes in a modular number space. If you want to understand what that means, I recommend a crypto mathematics course. I'm a bit shaky on it myself.

>> All you need is one of the "secret colours" and you're in

>> So it only works if the secret is regularly changed doesn't it?

Yup, and in the case of DHE (I'm unsure with plain DH) the 'secret' (or its parameters) are changed and then discarded with every connection. As discussed, with RSA this isn't really practical due to the computational cost.

0
0
Boffin

If they have the private key they can MITM diffie hellman too

Perfect forward secrecy using DH key exchange and throwing the session key away afterwards can only be authenticated to stop Eve who works for the NSA doing a MITM attack with both Alice and Bob (who think they have a direct connection) using either RSA or a pre-shared secret for authentication. If Eve has the secrets involved she can do a MITM here and subvert the session. Perfect forward secrecy only works in respect of session which occurred previously to Eve obtaining the long-term secrets used by Alice and Bob to authenticate each other. There may also be some advantage to using Diffie Hellman keys if Eve wants to do some fishing after the event using her vast session recording database and isn't actively monitoring Alice and Bob's communications with each other in real time.

0
0

Re: If they have the private key they can MITM diffie hellman too

Yes, the attack requires active participation in the data stream, whereas without Diffie Hellman you can decode it at your leisure later.

0
0

Page:

This topic is closed for new posts.

Forums