If they're used properly, they actually enhance encapsulation.
You often need to split a class in half when the two halves will have different numbers of instances or different lifetimes. In these cases, the two halves usually need direct access to each other (the two halves used to be in the same class, so you haven't increased the number of methods that have direct access to a data structure; you've simply moved some of those methods). The safest way to implement this is to make the two halves friends of each other.
If you use friends like just described, you'll keep private things private. In a naive effort to avoid using friendship in situations like the above, many people actually destroy encapsulation by either using public data (grotesque!), or by making the data accessible between the halves via public get/set methods. Having a public get and set method for a private datum is ok only when the private datum "makes sense" from outside the class (from a user's perspective). In many cases, these get/set methods are almost as bad as public data: they hide (only) the NAMES of the private data members, but they don't hide the existence of the private data members.
Similarly, if you use friend functions as a syntactic variant of a class's public access functions, they don't violate encapsulation any more than a member function violates encapsulation. In other words, a class's friends and members are the encapsulation barrier, as defined by the class itself.